Openheid in innovatie
Lessen uit Open Source voor nieuwe product ontwikkeling.Student: D. Brouwer
Studentnummer: 1441787
Openheid in innovatie
Lessen uit Open Source voor nieuwe product ontwikkeling“You can’t use an old map to find new land” – Gary Hamel
Student: Daniël Brouwer
Studentnummer: 1441787
Onderwijsinstelling: Rijksuniversiteit Groningen Instituut: Bedrijfskunde
Richting: Business Development Cursus: Afstudeeronderzoek/scriptie Afstudeerbegeleiders: Leenders, dr R.T.A.J.
Voorwoord
Voor u ligt de scriptie die is geschreven in het kader van de afronding van mijn opleiding Bedrijfskunde met als afstudeerspecialisatie Business Development. Dit onderzoek is tot stand gekomen uit eigen interesse.
Sinds enkele jaren ben ik zeer geïnteresseerd in Open Source software. In beginsel alleen het gebruik en de toepassing daarvan, later raakte ik gefascineerd door het proces en de organisatie waarop deze software tot stand komt.
Het licentiemodel van Open Source Software stelt in staat dat broncode vrij toegankelijk is. Hierdoor is het mogelijk dat iedereen kan/mag bijdragen aan de ontwikkeling ervan. Ondanks het schijnbaar complexe en chaotische proces dat hierdoor ontstaat, is het model in staat tot kwalitatief hoogwaardige software met een aanzienlijk korte ‘time-to-market’ en een nauwe aansluiting bij klantwensen. Dit werpt interessante vragen op voor het bedrijfsleven en de manier waarop zij haar innovatieproces benadert. Kan zij voordeel behalen door openheid?
Met dit idee heb ik Twynstra The Bridge benaderd en samen met Colin Willems en Wouter van der Burg hebben we dit idee verder vorm gegeven. Het resultaat daarvan ligt voor u.
Openheid is lastig. Zo bleek ook tijdens het schrijven van deze scriptie. Het Open Source concept stoelt met name op korte ontwikkeliteraties waartussen controle en feedback plaatsvindt door derden, aan de hand waarvan bijsturing plaats vindt. Voor iemand die een onderzoek baseert op dit concept zou je verwachten dat zijn onderzoeksvoortgang op dergelijke wijze plaats had. De realiteit is anders. Zonder dat ik me ervan bewust was hield ik me bij het schrijven van deze scriptie en het doen van het onderzoek aan de ´traditionele´ wijze van ontwikkelen, i.e. zo ver mogelijk doorontwikkelen voordat derden het onder ogen krijgen. Dit benadrukte hoe lastig het is van ‘mindset’ te veranderen.
Graag wil ik de volgende personen hartelijk danken: Colin Willems van Twynstra The Bridge voor zijn voortdurende advies en begeleiding tijdens het onderzoek. Alle andere medewerkers van Twynstra The Bridge voor hun medewerking en kennis. Wouter Pijzel, directeur van de Nederlands Orde van Uitvinders, voor de tijd die hij heeft kunnen vrijmaken in zijn drukke agenda voor een interview. [respondent a] van [bedrijf a], [respondent b] van [bedrijf b] en [respondent c], manager nieuwe media & innovatie bij [bedrijf c], voor hun interesse en de tijd die zij hebben vrij gemaakt voor interviews. Ritzo ten Cate, vriend en mede-directeur van De Ondernemers BV, voor zijn kritische blik op deze scriptie en advies. Mijn begeleiders Peter Muller en Roger Leenders van de Rijksuniversiteit Groningen voor hun inzet en terugkoppeling. Mijn vriendin voor haar geduld en advies tijdens mijn onderzoek. Iedereen die ik mogelijk vergeten ben.
Tot slot wil ik mijn ouders hartelijk danken voor hun steun en toeverlaat en de kans die ze me hebben gegeven mijn ambities na te jagen.
Inhoudsopgave
Voorwoord...- 3 -
Inhoudsopgave...- 4 -
1 Probleemverkenning ...- 6 -
1.1 Inleiding...- 6 -
1.2 Aanleiding van het onderzoek...- 6 -
1.3 Probleemanalyse...- 7 - 2 Probleemstelling...- 9 - 2.1 Inleiding...- 9 - 2.2 Doelstelling...- 9 - 2.3 Vraagstelling ...- 9 - 2.4 Randvoorwaarden ...- 10 -
2.5 Beschrijving beoogt concept adviesinstrument ...- 10 -
3 Theoretisch kader...- 12 -
3.2 Definities gebruikte termen...- 12 -
3.3 De bril van het onderzoek ...- 14 -
3.3.2 Het 7-S model...- 15 -
3.4 Deelvragen...- 16 -
3.5 Onderzoeksopzet als conceptueel model ...- 17 -
4 Onderzoeksopzet ...- 19 -
4.1 Inleiding...- 19 -
4.2 Type onderzoek ...- 19 -
4.3 Bronnen ...- 19 -
4.4 Dataverzamelingsmethode en betrouwbaarheid & validiteit ...- 19 -
5 Open Source software ontwikkeling: proces en organisatie ...- 22 -
5.1 Inleiding...- 22 -
5.2 Open Source: het ontwikkelproces...- 22 -
5.3 Open Source: de organisatie...- 26 -
6 New Product Development: proces en organisatie...- 39 -
6.1 Inleiding...- 39 -
6.2 New Product Development: het ontwikkelproces ...- 39 -
6.3 New Product Development: de organisatie...- 43 -
7 Kenmerkende verschillen tussen beide ontwikkelparadigma...- 49 -
7.1 Inleiding...- 49 -
7.3 Kenmerkende verschillen in organisatie ...- 51 -
7.4 Vereniging kenmerken en causale relatie...- 59 -
7.10 Samenvatting...- 61 -
8 Condities, beoordeling en oplossingsrichtingen ...- 62 -
8.1 Inleiding...- 62 -
8.2 Condities Open Source kenmerken...- 62 -
8.3 Beoordeling en oplossingsrichting ...- 69 -
9 Het concept adviesinstrument ...- 83 -
9.1 Inleiding...- 83 -
9.2 Kanttekening bij het concept adviesinstrument ...- 83 -
9.3 Toelichting bij het concept adviesinstrument ...- 83 -
10 Toetsing van het concept adviesinstrument:...- 85 -
Reacties uit de praktijk ...- 85 -
10.1 Inleiding...- 85 -
10.2 Opzet toetsing ...- 85 -
10.3 Kanttekeningen bij de toetsing ...- 85 -
10.4 [bedrijf a]: [respondent a] ...- 86 -
10.5 [bedrijf b]: [respondent b]...- 87 -
10.6 [bedrijf c]: [respondent c]...- 88 -
10.7 Conclusie over opmerkingen respondenten en adviesinstrument ...- 89 -
10.8 Conclusie over het toetsingsresultaat ...- 95 -
11 Conclusies en aanbevelingen ...- 97 -
11.1 Inleiding...- 97 -
11.2 Conclusies...- 98 -
11.3 Aanbevelingen ...- 99 -
1 Probleemverkenning
1.1
Inleiding
Een onderzoeksopzet bestaat uit de aanleiding van het onderzoek, een probleemanalyse, de probleemstelling, het theoretisch kader en wordt afgesloten met een beschrijving van het beoogde kennisproduct.
In paragraaf 1.2 wordt de aanleiding voor het onderzoek beschreven. In paragraaf 1.3 wordt de analyse beschreven die nader bepaald waar het nu precies om gaat in dit onderzoek.
In het volgende hoofdstuk wordt vervolgens de probleemstelling uiteengezet.
1.2
Aanleiding van het onderzoek
Ondernemingen hebben te maken met een steeds sneller veranderende consumentenvoorkeur. Consumenten zijn steeds minder gehecht aan vertrouwde producten1 waardoor klantloyaliteit afneemt. Klanten zijn minder snel onder de indruk van nieuwigheden, kopen wat toevallig in de aanbieding is en raken sneller verveeld (SwamiPersaud, 2003).
Ondernemingen wapenen zich hier veelal tegen door middel van productdifferentiatie strategieën. Een wildgroei aan producten, productcombinaties en producteigenschappen is het gevolg.
Voor consumenten kan dit verwarrend zijn (Prahalad & Ramaswamy, 2003) en voor ondernemingen hoge risico’s en kosten met zich mee brengen, want, zo stellen Tidd et al. (2001), een geschatte 38% van productideeën haalt de marktintroductie niet en gemiddeld 40% van de op de markt geïntroduceerde producten faalt.
Onderzoek naar succesfactoren van innovatie benadrukt veelal het belang van het bieden van uniek consumentenvoordeel. Bovendien suggereren onderzoeksresultaten dat hiervoor grondige kennis nodig is over welke elementen van een product of dienst verantwoordelijk zijn voor deze waardetoevoeging voor zowel de consument als de onderneming. Concurrentievoordeel en innovatiesucces worden voornamelijk behaald door het samen kunnen brengen van technische kennis en marktkennis (Robberst, Baker & Walker, 2005). Baker (2003) bekrachtigt dit punt door te benadrukken dat marktkennis nodig is om klantwaarde toe te kunnen voegen.
Consumenten zijn steeds beter geïnformeerd en bewuster over hun onderhandelingspositie. Niet zelden komt het voor dat een consument prijs en productinformatie bestudeert en vergelijkt voordat zij de winkel binnenstapt (Hijnk, 2005). Het internet biedt een overvloed aan websites met product en prijsvergelijkingen en fora waar consumenten meningen en ervaringen delen. De communicatie van consument-tot-consument is hierdoor geïntensiveerd, waardoor consumenten minder afhankelijk zijn van de informatie die een onderneming biedt. Consumenten hebben meer macht en mogelijkheden te kiezen welke onderneming/producten het beste voldoet aan hun criteria (Prahalad & Ramaswamy, 2004). De industrie wordt hierdoor voor de consument steeds transparanter.
In het traditionele innovatieparadigma staat de consument buiten het waarde-toevoegingproces. Waarde toevoeging gebeurt binnen de onderneming waarna aansluiting wordt gezocht op de markt (Prahalad & Ramaswamy, 2004). Men zou kunnen stellen dat de markt in dit paradigma wordt gezien als een statisch veld, ingedeeld in begrijpelijke consumentgroepen. Ondernemingen trachten met hun producten waarde toe te voegen voor gerichte consumentengroepen.
Ondernemingen voelen hierdoor steeds meer druk om in dialoog te gaan met de consument om op deze wijze betere toegang te krijgen tot marktkennis ten einde betere aansluiting op de markt
1
te vinden (Prahalad & Ramaswamy, 2004).
Veel auteurs spreken met betrekking tot deze ontwikkeling over de noodzaak tot een nieuw innovatieparadigma. Een paradigma dat is gebaseerd op huidige trends. Enkele termen die daarbij gebruikt worden zijn Experience Innovation (Prahalad & Ramaswamy, 2003), Co-creating (o.a. Prahalad & Ramaswamy, 2004), Co-developing (o.a. Von Hippel & Thomke, 2002) en Open Innovation (Chesbrough, 2003).
Het goede nieuws volgens Prahalad en Ramaswamy (2004) is dat de consument, gewapend met nieuwe tools en ontevredenheid over het aanbod bereid is bij te dragen.
In samenwerking met Twynstra The Bridge is nagedacht over deze ontwikkelingen. Wat speelt er en wat is er veranderd? Het lijkt erop dat de markt een andere vorm aangenomen heeft. Hij is van een statisch veld met weinig onderlinge communicatie veranderd in een dynamisch veld met zeer intensieve onderlinge communicatie. Ook transparantie of openheid lijkt een belangrijk aspect geworden voor consumenten (Prahalad en Ramaswamy, 2004).
De ontwikkeling dat steeds meer ondernemingen bereid zijn in dialoog te gaan met de markt duidt er sterk op dat ook zijn bereid zijn meer openheid in zaken te geven. Het uiteindelijke doel is natuurlijk het bieden van uniek consumentenvoordeel.
Vervolgens is nagedacht over mogelijke manieren om naar deze fenomenen te kijken. Zijn er modellen die met soortgelijke aspecten te maken hebben en antwoorden kunnen geven op vraagstukken met betrekking tot verschuiving richting openheid en winst van klantloyaliteit? Het ontwikkelproces van Open Source software lijkt een antwoord te kunnen bieden op vraagstukken over openheid. Het licentiemodel van Open Source software maakt het mogelijk dat iedereen kan en mag bijdragen aan ontwikkeling. Open Source software kent tevens een trouwe en in omvang toenemende gebruikersgroep en het stelt de gebruiker centraal waardoor het nauw aansluit bij gebruikersbehoeften. Tevens lijkt het model in staat tot kwalitatief hoogwaardige producten met een aanzienlijk korte ontwikkeltijd. Hiermee lijkt Open Source een bron van potentieel waardevolle informatie. Het snel kunnen ontwikkelen van producten die nauw aansluiten bij klantbehoeften en als van goede kwaliteit worden ervaren is iets dat voor veel ondernemingen zeer interessant is.
1.3
Probleemanalyse
Twynstra The Bridge heeft als voortdurende doelstelling verbeterde positionering in de markt door inhoudelijke kennis over ontwikkelingen op het gebied van innovatie.
Zij denkt een toenemende belangstelling waar te nemen voor Open Source als methode voor het ontwikkelen van nieuwe producten. Trends in de markt lijken volgens haar in toenemende mate te verschuiven richting open samenwerkingsvormen. Te denken valt hierbij aan de zogeheten wiki’s op het internet waarbij de tekstuele inhoud door gebruikers kan worden aangepast, op dergelijke wijze treedt een proces op waarbij men uit vrije wil teksten plaatst en aanpast. Andere voorbeelden van vrije en open samenwerkingsvormen zijn te vinden in de bio-industrie, muziekindustrie en het bedrijfsleven. Voorbeelden hiervan zijn respectievelijk
www.wikipedia.nl, www.cambia.com, www.magnatune.com en www.innocentive.com. Voor nadere toelichting wordt verwezen naar de betreffende websites.
Zij vermoedt dat deze belangstelling is gebaseerd op werkelijke toegevoegde waarde en niet alleen een modeverschijnsel is.
Het probleem van Twynstra The Bridge kan worden beschreven als het verschil tussen gewenste kennis en huidige kennis. Zij vermoedt dat Open Source een toegevoegde waarde biedt en wil weten waarop die toegevoegde waarde stoelt om zo haar klanten beter te kunnen adviseren. Twynstra The Bridge wil daarvoor meer inhoudelijke en pragmatische kennis hebben over het fenomeen Open Source. Met deze kennis kan zij vervolgens vaststellen of en hoe zij hierop een feitelijk adviesinstrument kan baseren. Gesteld kan worden dat het probleem van Twynstra The Bridge is te typeren als een kennisbehoefte.
2 Probleemstelling
2.1
Inleiding
Een probleemstelling bestaat uit een doelstelling en een logisch daaruit afgeleide vraagstelling afgebakend door randvoorwaarden die aan het onderzoek worden gesteld. Samen leggen ze precies vast wat onderzocht wordt en waarom (De Leeuw, 1996; Verschuren, 1992 beiden in De Leeuw, 2001). De probleemstelling geeft het onderzoek vorm.
In de doelstelling wordt bepaald voor wie het onderzoek wordt uitgevoerd, wat er voor hen (waarschijnlijk) uitkomt en waarom dat voor de betrokken partijen relevant is.
2.2
Doelstelling
Doel van dit onderzoek is het ontwikkelen van een concept adviesinstrument, gebaseerd op toegevoegde waarde van de OSS-ontwikkelmethode ten opzichte van traditionele NPD-methoden. Dit concept adviesinstrument dient te worden getoetst op relevantie bij klanten van Twynstra The Bridge nadat de inhoudelijke kennis en het concept adviesinstrument is ontwikkeld.
Het concept adviesinstrument draagt bij aan de inhoudelijke kennis van Twynstra the Bridge en haar positionering in de markt doordat met opgedane kennis naar buiten getreden wordt in de vorm van een publicatie in een vakblad. Op deze wijze tracht Twynstra The Bridge zichzelf te positioneren als experts op het gebied van Open Source ontwikkelmethoden en wil zij haar inhoudelijke kennis commercieel inzetten.
De toetsing op relevantie duidt op een vaststelling van het raakvlak tussen de kennis uit het concept adviesinstrument en de praktijk van klanten van Twynstra The Bridge. Er wordt, met andere woorden, getoetst of het onderzoeksresultaat niet te ver van de praktijk en de belevingswereld van klanten van Twynstra The Bridge af ligt. Dit is een belangrijke voorwaarde voor Twynstra The Bridge om te komen tot een besluit voor het al dan niet doorontwikkelen tot een volwaardig adviesinstrument.
2.3
Vraagstelling
Hoe kan op basis van de toegevoegde waarde van de OSS-ontwikkelmethode, als die er is, een conceptadviesinstrument worden ontwikkeld die interessant is voor klanten van Twynstra The Bridge om mee te worden geadviseerd?
Deze vraagstelling valt uiteen in drie hoofdvragen:
I) Wat is de toegevoegde waarde van de OSS-ontwikkelmethode?
II) Hoe kan de gevonden toegevoegde waarde worden ingezet door Twynstra The Bridge om haar klanten te adviseren over open samenwerkingsvormen bij innovatie en productontwikkeling?
III) Is het concept adviesinstrument, gebaseerd op de toegevoegde waarde, bruikbaar in de praktijk?
Definitie termen:
• Concept adviesinstrument: zie paragraaf 2.5.
• Toegevoegde waarde: De toegevoegde waarde waarover in deze scriptie gesproken wordt is gebaseerd op de aanname dat het OSS-ontwikkelproces in staat is tot snelle ontwikkeling van producten die nauw aansluiten bij gebruikersbehoeften en als kwalitatief hoogwaardig worden ervaren. De toegevoegde waarde heeft hierbij betrekking op die kenmerken die in de OSS-ontwikkelmethode wel voorkomen en in traditionele NPD-ontwikkelmethoden niet.
• Ontwikkelmethode: de organisatie en het proces van de OSS ontwikkeling. Dit zal worden beschreven aan de hand van het theoretisch kader.
• Toetsen van bruikbaarheid: Het betreft hier toetsing van het model op raakvlak met de praktijk van klanten van Twynstra The Bridge. Het model zal minder of niet bruikbaar zijn als het geen aansluiting vindt bij de praktijk van klanten. Het model komt in aanmerking voor doorontwikkeling wanneer het (deels) aansluit bij de praktijk van klanten van Twynstra The Bridge. Het model zal volgens Colin Willems ook bruikbaar zijn en in aanmerking komen voor doorontwikkeling wanneer klanten van Twynstra The Bridge herkenning (raakvlak tussen theorie en praktijk) en interesse tonen in de verkregen onderzoeksresultaten. Interesse wordt hier gedefinieerd als belangstelling voor de gevonden onderzoeksresultaten. Wanneer deze belangstelling groot genoeg is, en dit is een subjectief oordeel, zal volgens Willems de kans aanwezig zijn dat er toekomstige opdrachten uit voortvloeien.
2.4
Randvoorwaarden
Proces randvoorwaarden• Om vast te stellen dat gevonden Open Source kenmerken uniek zijn voor dit paradigma zal het traditionele NPD-proces in hetzelfde theoretisch kader worden geplaatst en worden vergeleken.
• Het onderzoeksproces beslaat vier maanden.
• Als de hypothese wordt gefalsificeerd kan worden verondersteld dat de ontwikkelmethode van OSS geen toegevoegde waarde biedt voor innovatie. Hiermee wordt wel meer inhoudelijke kennis verschaft in het domein Open Source, maar een slag om gevonden kennis pragmatisch toepasbaar te maken voor adviseurs zal dan niet nodig zijn.
• De dataverzameling uit de literatuur zal gedurende het onderzoek continu in overleg via ongestructureerde interview of creatieve sessies/brainstorm sessies worden aangevuld. De reden hiervoor is tweeledig: 1) het houdt de medewerkers van Twynstra The Bridge continu betrokken bij het onderzoek en 2) het houdt de onderzoeksresultaten dicht bij de belevingswereld van Twynstra The Bridge.
Product randvoorwaarden
• Het resultaat van dit onderzoek is een conceptueel model dat de succes kenmerken van OSS-ontwikkeling plaatst in het traditionele NPD paradigma, getoetst in de praktijk. • Als uit onderzoek blijkt dat de gevonden kenmerken niet in een traditioneel NPD-proces
te plaatsen zijn, of wanneer ze geen nieuwe inzichten opleveren, zal het onderzoek niet resulteren in een conceptueel model. Een artikel over de onderzoeksresultaten zal dan dienen als marketinginstrument. Het doel van Twynstra The Bridge (inhoudelijke kennis waarmee naar buiten getreden kan worden ten einde een verbeterde positionering in de markt) is daarmee geenszins mislukt.
• Het toetsen van het concept adviesinstrument bestaat uit twee delen. Ten eerste zal dataverzameling uit de literatuur gedurende het onderzoek continu in overleg via ongestructureerde interview of creatieve sessies/brainstorm sessies worden aangevuld. De reden hiervoor is tweeledig: 1) het houdt de medewerkers van Twynstra The Bridge continu betrokken bij het onderzoek en 2) het houdt de onderzoeksresultaten dicht bij de belevingswereld van Twynstra The Bridge.
2.5
Beschrijving beoogt concept adviesinstrument
Het model duidt de toegevoegde waarde van OS-ontwikkelmethoden aan. Het model biedt zogezegd een expliciet referentiemodel voor openheid in innovatie volgens de Open Source methode. Een expliciet referentiemodel betreft de kenmerken die voor het bereiken van bepaalde doelen relevant worden geacht (de Leeuw, 2002). In dit geval zijn dit kenmerken die relevant worden geacht voor het bereiken van de “toegevoegde waarde van Open Source”.
3 Theoretisch kader
3.1
Inleiding
In dit hoofdstuk worden allereerst de definities gegeven van enkele termen die in deze scriptie veel voorkomen. Het stelt de lezer in staat te begrijpen wat er met bepaalde termen wordt bedoeld en wat niet.
Daarna wordt het theoretische raamwerk beschreven waarop het onderzoek stoelt. Dit theoretische raamwerk zijn die modellen die in dit onderzoek zijn gebruikt om de ontwikkelmethoden van OSS en NPD te bekijken en te beschrijven. Ze zijn als het ware de bril waarmee wordt gekeken. In dit hoofdstuk wordt alleen het theoretisch raamwerk uitgewerkt dat gebruikt is om zowel OSS als NPD te beschrijven. Theorieën en modellen die alleen voor het beschrijven van dan wel OSS, dan wel NPD, zijn gebruikt worden in de bijbehorende tekst toegelicht.
Vervolgens worden in paragraaf 3.4 de hoofdvragen opgedeeld in deelvragen. De beantwoording van deze deelvragen zal tezamen het antwoord geven op de vraagstelling en resulteren in het concept adviesinstrument dat Twynstra The Bridge doormiddel van dit onderzoek wil laten ontwikkelen.
Tot slot wordt in dit hoofdstuk het conceptueel model van het onderzoek gegeven. Dit model geeft de verbanden weer die van invloed zijn op het beantwoorden van de hoofdvraag, de vraagstelling, en biedt een grafische weergaven van de stappen en verbanden in dit onderzoek.
3.2
Definities gebruikte termen
In deze paragraaf worden de definities gegeven van de meest gebruikte termen in deze scriptie. Allereerst wordt de officiële, volledige definitie van Open Source software gegeven. Dit stelt in staat beter te begrijpen op welke principes het Open Source idee is gebaseerd.
Daarna wordt aangegeven wat in deze scriptie wordt verstaan onder OSS-ontwikkeling, NPD-ontwikkeling, (traditionele) NPD en innovatie.
Termen die minder vaak voorkomen worden in deze scriptie ter plaatse gedefinieerd in de tekst.
3.2.1
Open Source software (OSS)
Simplistisch gesteld is Open Source software, software waarvan de broncode2 vrij toegankelijk is. De software mag door iedereen worden gebruikt voor ieder gewenst doeleinde, zolang de originele auteurs worden erkend. Het licentiemodel van Open Source stelt expliciete eisen aan de distributie van de software om de openheid ook in de toekomst te waarborgen en moet derhalve voldoen aan de volgende criteria3:
1. Vrije distributie
Het licentiemodel mag het verkopen of weggeven van de software als onderdeel van een verzameling software niet verbieden. Ook mag het licentiemodel geen compensatie vragen voor het verkopen of weggeven in de vorm van royalty’s.
2. Broncode
De software moet gedistribueerd worden inclusief de broncode en moet herdistributie van de broncode alsook van het gecompileerde programma toestaan. Wanneer distributie zonder
2 Broncode: alle instructieregels waaruit software (een computerprogramma) bestaat. Dit is de tekst die een programmeur in een formele programmeertaal schrijft. Het is iets dat de meeste gebruikers van software nooit zullen zien, zeker niet bij gebruik van commerciële software omdat de broncode daar is afgeschermd.
broncode plaats vindt moet de broncode welbekend (publiekelijk) toegankelijk zijn, tegen redelijke reproductiekosten, liefst gratis te downloaden via het internet. Het opzettelijk verduisteren of onleesbaar maken van de broncode is niet toegestaan.
3. Afgeleide werken
De licentie moet modificatie en herdistributie van afgeleide werken toestaan. Herdistributie van gemodificeerde of afgeleide werken dient te worden gedaan onder dezelfde voorwaarden.
4. Integriteit van de auteurs broncode
De licentie mag de verplichting opleggen dat gemodificeerde broncode wordt gedistribueerd onder een andere naam of versienummer.
5. Geen discriminatie tegen personen of groepen
De licentie mag niet discrimineren. Dit betekent dat iedereen, ras, leeftijd, groep, organisatie de software mag gebruiken.
6. Geen discriminatie tegen toepassingsgebieden
De licentie mag niet verbieden dat de software wordt gebruikt voor bepaalde doeleinden. 7. Distributie van de licentie
Alle rechten verbonden aan de software moeten op ieder die het gebruikt van toepassing zijn zonder dat additionele overeenkomsten moeten worden gesloten.
8. De licentie mag niet van toepassing zijn op een specifiek product
De rechten verbonden aan de software mogen niet verbonden zijn aan dat product. Dit betekent dat de licentie niet alleen van kracht moet zijn op de software in deze specifieke vorm met deze specifieke taken. Ook wanneer de software een deel van een groter geheel is, of wanneer van de software een specifiek deel herdistribueert wordt dienen dezelfde rechten van kracht te zijn. 9. De licentie mag andere software niet beïnvloeden
De licentie mag niet bepalen dat software die samen met de open source software wordt gedistribueerd ook onder het open source licentiemodel valt.
10. De licentie moet technologieonafhankelijk zijn
Geen enkel onderdeel van de licentie mag betrekking hebben op een specifieke technologie of interface.
3.2.2
OSS-ontwikkeling
OSS-ontwikkeling heeft betrekking op het ontwikkelen van Open Source software. In deze scriptie zal worden gesproken over Open Source (OS), Open Source software (OSS), Open Source ontwikkeling (OSS-ontwikkeling), Open Source ontwikkelmethode(n) (OSS-ontwikkelmethoden).
3.2.3
New Product Development (NPD)
New Product Development, NPD vanaf hier, heeft betrekking het proces van nieuwe product ontwikkeling. Het beslaat alle stappen/fasen van idee tot lancering op de markt (Baker & Hart, 1999).
worden zijn niet ultiem. Dat wil zeggen: het geeft niet weer hoe het altijd en overal is. Er wordt een “grootste gemene deler” van alle NPD aspecten beschreven. Er zullen dus situaties en contexten zijn waarin het anders gebeurd dan zoals beschreven in deze scriptie. Het is echter onmogelijk om alle mogelijke NPD methoden e.d. te beschrijven.
Wanneer alleen gekeken zou worden naar een bepaald aspect van NPD zou de kans bestaan dat aspecten van OSS-ontwikkeling uniek lijken terwijl dat niet zo is.
3.2.4
Innovatie
Het VanDale Hedendaags Nederlands woordenboek definieert innovatie als: “invoering van iets nieuws”. In deze scriptie wordt innovatie gedefinieerd als:
• nieuwe dingen doen,
• dingen op een nieuwe manier doen,
• nieuwe dingen op een nieuwe manier doen,
Hierbij is expliciet gekozen voor “dingen”, om geen onderscheid te maken tussen producten en diensten, omdat innovatie op beide van toepassing kan zijn. Voor het woord “doen” is gekozen omdat innovatie niet altijd per se van toepassing is op ontwikkelen maar ook op uitvoeren. Veel auteurs maken een onderscheid tussen inventie en innovatie. Inventie wordt daarbij vaak gedefinieerd als “een ontdekking of uitvinding” (o.a. VanDale) en innovatie als “een succesvolle commercialisering van een uitvinding of ontdekking”.
3.3
De bril van het onderzoek
In deze paragraaf worden de theoretische modellen beschreven waarmee het proces en de organisatie van zowel OSS-ontwikkeling als NPD worden bekeken en beschreven. Deze modellen vormen als het ware de bril vormen waarmee in dit onderzoek is gekeken. Dit is handig doordat het in staat stelt op een zelfde wijze naar beide ontwikkelmethoden te kijken, anderzijds stellen modellen beperkingen aan de aspecten waarnaar men kijkt.
3.3.1
Trail-and-error cyclus
Om het proces van ontwikkeling in zowel OSS als NPD te beschrijven is het verstandig van een model gebruik te maken. Dit dwingt namelijk beide aspecten op gelijke wijze te bekijken. Om te voorkomen dat voor een model gekozen wordt dat een betere aansluiting vindt bij een van beide processen is gekozen een model te gebruiken dat teruggrijpt naar de essentie van een ontwikkelproces. Doordat het ontwikkelen van een product in de kern bestaat uit het oplossen van een probleem (Von Hippel, 2005) is gekozen om de trail-and-error cyclus (figuur 4-1) zoals von Hippel deze in zijn boek Democratizing Innovation (2005) beschrijft, te gebruiken om in hoofdstuk 7 de verschillen tussen het ontwikkelproces van OSS en NPD vast te kunnen stellen. Onderzoek naar de aard van probleemoplossing, uitgevoerd door Baron (1988 in Von Hippel, 2005), toont aan dat probleemoplossing bestaat uit een trail-and-error cyclus die richting krijgt door een notie over de oplossingsrichting en enig inhoudelijk inzicht. Product en service ontwikkeling bestaat in de kern ook uit trail-and-error (Marples 1961; Allen, 1966; Von Hippel & Tyre, 1995; Thomke 1998, 2003 in Von Hippel 2005).
Uitleg bij figuur 3-1:
Bij activiteit 1 worden behoefte en oplossingsinformatie gecombineerd om een ontwerp voor het idee te vormen. Bij activiteit 2 wordt een model of prototype ontwikkeld van het idee. Bij activiteit 3 wordt het model of prototype getest in de werkelijke gebruiksomgeving of in een gesimuleerde/representatieve omgeving. Bij activiteit 4 worden de resultaten van de test geanalyseerd om te leren en vervolgens het ontwerp aan te passen.
Figuur 3-1: probleemoplossingcyclus van productontwikkeling (Von Hippel, 2005)
3.3.2 Het 7-S model
Om de organisatie van zowel OSS-ontwikkeling als NPD te beschrijven is gezocht naar een model dat een zowel naar harde als zachte aspecten4 van organisatie kijkt en een model dat een zo compleet mogelijke beschrijving kan geven van de architectuur van (een) organisatie. De reden hiervoor is dat bij aanvang van het onderzoek, buiten de grondaanname dat er verschillen zijn, geen idee bestaat van waar deze verschillen zitten. Het is daarom van belang zo breed mogelijk te zoeken.
Het 7-S model van Richard Pascale, Tom Peters en Robert Waterman biedt een raamwerk om een organisatie kwalitatief te bekijken. Elke “S” vormt in dit model een belangrijk aandachtspunt bij het bekijken van de architectuur van een organisatie. Bij een effectieve organisatie en optimale prestatie ondersteunen en versterken de zeven S-en elkaar doordat er een onderlinge “fit” is. Hiermee blijkt het 7-S model een geschikt model omdat het de twee voorwaarden (compleet: harde en zachte aspecten, en architectuur) belicht.
De zeven S-en staan voor Engelstalige termen die ik hieronder heb vertaald. De oorspronkelijke Engelse term staat er tussen haakjes achter. De S-en kunnen worden verdeeld in drie harde en vier zachte organisatieaspecten. Harde aspecten zijn meer tastbaar: Strategie, Structuur en Systemen. De zachte aspecten zijn minder tastbaar: Significante waarden, Stijl van leidinggeven, Staf en Sleutelvaardigheden.
De organisatie van OSS-ontwikkeling en het NPD-proces worden beschreven aan de hand van het 7-S model van McKinsey. Dit model is bedoeld om de effectiviteit van een totale organisatie te beoordelen. Het kan echter met dezelfde effectiviteit worden gebruikt om de organisatie van deelsystemen te analyseren (Johne & Snelson, 1988). Er is voor dit model gekozen omdat het een
4 Met harde factoren wordt gedoeld op factoren die zich vrij gemakkelijk zijn te begrijpen en doorgronden/beschrijven/ontwerpen. Zachte factoren hebben betrekking op minder gemakkelijk te begrijpen/beschrijven/ontwikkelen aspecten. Voorbeelden zijn respectievelijk de organisatiestructuur en de organisatiecultuur.
1 Ontwerp
2 Ontwikkeling
3 Test
4 Analyse
• Ervaring van voorgaande cycli wordt gebruikt om een verbeterd ontwerp te realiseren.
• Een model wordt ontwikkeld en/of prototypes worden ontwikkeld om te gebruiken in lopende experimenten.
• Model/prototype wordt getest in een echte of gesimuleerde omgeving.
goed platform biedt ter illustratie van de effectiviteit van het OSS ontwikkelmodel en het handvatten biedt om dit model te koppelen aan de architectuur van een traditionele organisatie.
Strategie (Strategy)
De strategie betreft de doelen die worden nagestreefd door de organisatie en de manier waarop men deze probeert te bereiken.
Structuur (Structure)
De formele indeling in de vorm van niveaus, hiërarchie, functionele indeling. Of, de som van alle delen van de organisatie en de manier waarop coördinatie daartussen plaats vindt (Mintzberg, 1983).
Systemen (Systems)
Systemen zijn zowel informatiesystemen alsook formele en informele regels en procedures die gelden binnen een organisatie. Zaken als: hoe wordt het werk gedaan, wie zijn er bij betrokken en welke regels gelden er.
Figuur 3-2: Het 7-S model van McKinsey
Significante waarden (Shared values)
De significante waarden hebben betrekking op de cultuur en de identiteit van een organisatie. Cultuur is de collectieve mentale programmering, die de leden van een groep of categorie mensen onderscheidt van die van anderen (Hofstede, 1993). Het gaat daarbij om, onuitgesproken, normen en waarden die van kracht zijn binnen de organisatie.
Sleutelvaardigheden (Skills)
Dit element geeft aan waar de organisatie goed in is, wat zijn de kerncompetenties van de organisatie, waarin zijn ze beter dan andere organisaties.
Staf (Staff)
Het personeel. Hoe wordt personeel aangetrokken, aan welke voorwaarden moeten personeelsleden voldoen en hoe vind training/scholing plaats. Daarnaast wordt gekeken naar hoe personeel wordt/is gemotiveerd.
Stijl van leidinggeven (Style)
Hoe worden beslissingen genomen binnen een organisatie en welke autoriteit heeft een leider.
3.4
Deelvragen
beantwoording hiervan moeten verschillende deelvragen eerst worden beantwoord. In deze paragraaf zijn de drie hoofdvragen opgedeeld in deelvragen.
Deelvragen bij hoofdvraag I (Wat is de toegevoegde waarde van de OSS-ontwikkelmethode?): I/1 Welke kenmerken leiden bij de ontwikkeling van OSS tot snelle ontwikkeling van
producten die nauw aansluiten bij klantbehoeften en als kwalitatief hoogwaardig worden ervaren door de gebruiker?
a. Hoe ziet een Open Source software ontwikkelproces eruit?
b. Hoe ziet de organisatie van een Open Source software ontwikkelproces eruit?
I/2 Welke kenmerken leiden in een traditioneel NPD proces tot snelle ontwikkeling van producten die nauw aansluiten bij klantbehoeften en als kwalitatief hoogwaardig worden ervaren door de gebruiker?
a. Hoe ziet een traditioneel NPD proces eruit?
b. Hoe ziet de organisatie van een traditioneel NPD proces eruit? I/3 Welke kenmerken zijn uniek in Open Source in vergelijking met NPD?
Deelvragen bij hoofdvraag II (Hoe kan de gevonden toegevoegde waarde worden ingezet door Twynstra The Bridge om haar klanten te adviseren over open samenwerkingsvormen bij innovatie en productontwikkeling?):
II/1 In welke gevallen/hoe kunnen Open Source kenmerken hulp bieden om het traditionele NPD proces te verbeteren?
a. Aan welke condities zijn de Open Source kenmerken gebonden?
b. Hoe kunnen deze kenmerken worden bepaald in de klantspecifieke context? c. Welke oplossingsrichtingen zijn er wanneer een organisatie een bepaald
kenmerk op een Open Source manier wil inzetten?
II/2 Hoe kan gevonden Open Source kennis worden weergegeven in een concept adviesinstrument?
a. Welke kenmerken onderscheiden Open Source van NPD? b. Welke condities zijn hieraan verbonden?
c. Hoe kan worden beoordeeld door een adviseur hoe en of een dergelijk kenmerk bij de klant aanwezig is?
d. Welke alternatieve ontwerpen kunnen dienen als oplossingsrichting?
Deelvraag hoofdvraag III (Is het concept adviesinstrument, gebaseerd op de toegevoegde waarde, bruikbaar in de praktijk?):
III/1 Zijn klanten van Twynstra The Bridge geïnteresseerd in advies aan de hand van het ontwikkelde model?
III/2 Is er raakvlak tussen theorie en praktijk? Met andere woorden: sluiten de onderzoeksbevindingen aan bij de praktijk van klanten van Twynstra The Bridge?
3.5
Onderzoeksopzet als conceptueel model
Aan de hand van de probleemstelling en daarbij horende doelstelling en vraagstelling, uiteengezet in deelvragen, kan een conceptueel worden opgesteld. Dit conceptueel model geeft de verbanden weer die van invloed zijn op het beantwoorden van de hoofdvraag, de vraagstelling. Het is daarmee een grafische weergave van de stappen die tijdens het onderzoek zullen worden gezet.
Doel is te komen tot een getoetst concept adviesinstrument. Daarvoor moeten een tweetal zaken worden gedaan: er moet een concept adviesinstrument worden ontwikkeld en deze moet worden getoetst.
en tevredenheid te vergelijken met de kenmerken die datzelfde bereiken bij traditionele NPD. Het resultaat is een overzicht van de kenmerkende verschillen. Voor deze kenmerkende verschillen wordt vervolgens vastgesteld aan welke condities ze gebonden zijn, hoe kan worden beoordeeld of een kenmerk in de klantspecifieke situatie al volgens de OSS manier is ingevuld en uiteindelijk hoe men daartoe komt wanneer dat nog niet zo is.
Het toetsen van het concept adviesinstrument bestaat uit twee delen. Ten eerste zal dataverzameling uit de literatuur gedurende het onderzoek continu in overleg via ongestructureerde interview of creatieve sessies/brainstorm sessies worden aangevuld. De reden hiervoor is tweeledig: 1) het houdt de medewerkers van Twynstra The Bridge continu betrokken bij het onderzoek en 2) het houdt de onderzoeksresultaten dicht bij de belevingswereld van Twynstra The Bridge.
Ten tweede zal het concept adviesinstrument bij een aantal klanten van Twynstra The Bridge worden toegelicht en besproken ter evaluatie van het raakvlak van de theorie (het ontwikkelde model) en de bedrijfspraktijk van de klanten van Twynstra The Bridge.
Figuur 3-3: Conceptueel model van het onderzoek Getoetst concept adviesproduct
Concept adviesproduct Toetsing
Toelichting bij klanten Aanvulling theorie met praktijk- kennis door interviews Evaluatie van bruikbaarheid concept adviesproduct Beoordeling en oplossingsrichting tot OSS-kenmerken kunnen komen
Kenmerken ten grondslag liggen aan succesvolle OSSontwikkeling Proces OSS
ontwikkeling
Organisatie OSS ontwikkeling Kenmerken ten grondslag liggen
aan succesvolle NPD methoden Proces traditioneel NPD Organisatie traditioneel NPD Ja
4 Onderzoeksopzet
4.1
Inleiding
In dit hoofdstuk wordt de onderzoeksopzet toegelicht met de daarbij gebruikte methoden en manieren van dataverzameling. In de tweede paragraaf wordt het onderzoek getypeerd. In de derde paragraaf wordt aangegeven welke bronnen zijn geraadpleegd. In de vierde paragraaf, tot slot, komt de dataverzamelingsmethode en de betrouwbaarheid van de verzamelde data aan de orde.
4.2
Type onderzoek
De Leeuw (2001) typeert exploratief onderzoek als onderzoek dat verkent en ideeën of hypothesen vormt, het geeft daarmee antwoord op een open vraag.
Dit onderzoek is te typeren als exploratief. Het is een eerste iteratie in de ontwikkeling van een adviesinstrument op basis van Open Source kenmerken. Na dit onderzoek zal vastgesteld zijn of en wat kenmerkende verschillen zijn tussen de twee onderzochte ontwikkelmethoden, aan welke condities de eventueel gevonden kenmerken zijn gebonden en wat mogelijke oplossingsrichtingen zijn voor het implementeren van een bepaald kenmerk.
Hierna zullen mogelijk hypothesen gevormd kunnen worden die in een toetsend onderzoek zullen moeten worden bekrachtigd of gefalsificeerd. Deze verdere toetsing van de gevonden onderzoeksresultaten, het concept adviesinstrument, zal nodig zijn om vast te kunnen stellen of en het concept adviesinstrument in praktijk situaties nuttig toepasbaar is, om te voorkomen dat de gevonden onderzoeksresultaten gebaseerd zijn op toeval.
In dit onderzoek is eenmalig een questionnaire gebruikt. Het doel van deze questionnaire was tweeledig: ten eerste is het gebruikt om te putten uit de kennis van medewerkers van Twynstra The Bridge. Op deze manier is getracht richting te geven aan het onderzoek en zoveel mogelijk te waarborgen dat het onderzoeksresultaat binnen de belevingswereld van Twynstra The Bridge valt. Ten tweede is het als middel ingezet om de medewerkers van Twynstra The Bridge op de hoogte te houden van de inhoud en de richting van het onderzoek. Volgens het managementteam een waardevolle manier om medewerkers aan het denken te zetten en scherp te houden. Dit was een expliciete wens van Hans Bakker, managementteamlid.
4.3
Bronnen
In dit onderzoek zijn meerdere informatiebronnen gebruikt. Er is gebruik gemaakt van bedrijfskundige, antropologische, sociologische en (computer)technische literatuur in de vorm van boeken, publicaties, tijdschriften, het internet en artikelen. En er is gebruik gemaakt van kennis van medewerkers en klanten van Twynstra The Bridge.
4.4
Dataverzamelingsmethode en betrouwbaarheid & validiteit
Zoals hier boven te lezen was zijn er meerdere bronnen gebruikt in dit onderzoek. Informatie uit literatuur is verkregen door literatuurstudie, ook wel deskreseach (o.a. de Leeuw, 2001).
Informatie van medewerkers is verkregen door middel van een questionnaire en gestructureerde en ongestructureerde interviews of (expert)sessies. De toetsing bij klanten van Twynstra The Bridge is gedaan aan de hand van gestructureerde interviews en hadden meer het karakter van een dialoog dan van een eenzijdig vraaggesprek.
Dataverzameling valt onder te verdelen in 5 fasen. Onderzoeksfase 1) Probleemverkenning
Twynstra The Bridge is mijn onderzoeksvoorstel besproken en toegespitst op de kennisbehoefte van The Bridge. Aan de hand van literatuur (wetenschappelijke artikelen e.d.) zijn gegevens verzameld om meer inzicht te krijgen in de aanleiding van het onderzoek en de analyse van het probleem. Deze gegevens zijn gebaseerd op wetenschappelijke werken van meerdere toonaangevende auteurs/onderzoekers. De betrouwbaarheid van gegevens in deze fase kunnen als betrouwbaar worden gezien omdat meerdere bronnen en meerdere medewerkers zijn geraadpleegd om tot deze gegevens te komen.
Deze fase van het onderzoek is terug te lezen in hoofdstuk 1. Onderzoeksfase 2) Probleemstellen en theoretische achtergronden
De probleemstelling is samengesteld naar beste oordeel en steeds aangescherpt door ongestructureerde interviews (overleg) met de directe begeleider binnen Twynstra The Bridge, Colin Willems.
Daarnaast is gebruik gemaakt van meerdere bronnen op het gebied van methodologie om te komen tot een methodologisch correcte probleemstelling. De gebruikte theoretische concepten en het theoretische kader zijn doormiddel van literatuurstudie uitgewerkt.
De verzamelde gegevens in deze fase zijn betrouwbaar. Colin Willems van Twynstra the Bridge heeft een helder beeld kunnen schetsen van zijn kennisbehoefte en aan de hand van literatuur over het opzetten van een onderzoek is deze kennisbehoefte vertaald naar een onderzoeksopzet. De gegevens over theoretische achtergronden zijn betrouwbaar omdat ze zijn gebaseerd op verschillende bronnen.
Deze fasen van het onderzoek zijn terug te lezen in hoofdstukken 2 en 3. Onderzoeksfase 3) Beschrijving van OS en NPD
Beantwoording van deelvragen I/1 tot en met I/2.
Hoofdvraag I is beantwoord aan de hand van literatuurstudie. In verschillende bronnen is gezocht naar kenmerken van beide ontwikkelparadigma, binnen het theoretisch kader. De verzamelde gegevens in deze fase zijn betrouwbaar. De gegevens zijn gebaseerd op wetenschappelijke literatuur door meerdere toonaangevende auteurs/onderzoekers.
Een questionnaire werd ingezet na het beantwoorden van deelvraag I/1b. De questionnaire lichtte toe hoe het OSS ontwikkelparadigma, geplaatst in het theoretisch kader, is georganiseerd. De questionnaire diende, naast een stimulans tot denken binnen Twynstra The Bridge en middel om het onderzoek nader toe te lichten, als dataverzameling van aandachtspunten (en uitgangspunten) voor het beantwoorden van onderzoeksfase 5 (deelvraag II/1).
Onderzoeksfase 4) Vaststellen van kenmerkende verschillen Beantwoording van deelvraag I/3 .
Deelvraag I/3 is naar beste oordeel beantwoord door gegevens uit literatuur te vergelijken. In een ongestructureerd interview (expertsessie met twee medewerkers van Twynstra The Bridge) zijn de geconstateerde kenmerken nogmaals vergeleken en zijn de kenmerkende verschillen nader bepaald.
De verzamelde gegevens in deze fase zijn betrouwbaar. De gegevens zijn gebaseerd op wetenschappelijke literatuur van meerdere toonaangevende auteurs/onderzoekers.
Onderzoeksfase 5) Vaststellen hoe de kenmerkende verschillen kunnen worden toegepast Beantwoording van deelvraag II .
informatiebron in deze fase.
De uitkomst van deelvraag II/2 is een construct dat is ontstaan door naar beste oordeel schematisch weer te geven wat er uit literatuurstudie en de sessies met veranderkundigen naar voren kwam. Dit is het concept adviesinstrument dat als input dient voor fase 6.
De betrouwbaarheid van deze gegevens is gepoogd zo groot mogelijk te houden door triangulatie, het gebruiken van verschillende gegevensbronnen om ergens toe te komen. Het benoemen van condities van de kenmerkende verschillen is met name gebaseerd op literatuurstudie waarbij meerdere bronnen zijn gebruikt. Deze gegevens zijn daarmee betrouwbaar. Deelvragen II/1b en II/1c zijn het product van een dialoog (ongestructureerde interviews) met medewerkers van The Bridge gevolgd door verdere literatuurstudie. De uitkomsten daarmee ook betrouwbaar doordat verschillende medewerkers zijn benaderd en de daar hen verkregen gegevens zijn aangevuld door literatuurstudie.
Onderzoeksfase 6) Toetsing kenmerkende verschillen Beantwoording van deelvraag III .
Het concept adviesinstrument dat in de vorige fase is samengesteld werd in deze fase aan de hand van gestructureerde interviews met klanten van Twynstra The Bridge getoetst op praktische relevantie. Het doel was om te achterhalen of de onderzoeksresultaten volgens klanten van The Bridge praktisch en realistisch toepasbaar zouden zijn in hun praktijk. Deze toetsing was van belang voor The Bridge om vast te kunnen stellen in welke sectoren de onderzoeksresultaten de meeste aansluiting hadden en waar ze met het grootste enthousiasme werden ontvangen. Hierop baseert The Bridge de beslissing of zij het concept adviesinstrument verder wil uitwerken in de toekomst.
Betrouwbaarheid is ook hier getracht zo hoog mogelijk te houden door bij meerdere personen te toetsen. De betrouwbaarheid van deze gegevens zou echter vele malen groter zijn wanneer bij meerdere respondenten uit vergelijkbare branches getoetst zou worden.
5 Open Source software ontwikkeling: proces en organisatie
5.1
Inleiding
In dit hoofdstuk wordt ingegaan op het proces van Open Source software ontwikkeling en de organisatie daarvan. Hiermee zal een antwoord worden gegeven op deelvraag I/1 uit de onderzoeksopzet.
5.2
Open Source: het ontwikkelproces
De ontwikkeling van Open Source software bestaat uit vier fasen, te weten: • ideegeneratie fase (de fase waarin het idee voor een programma ontstaat),
• evaluatiefase (de fase waarin een idee wordt vrijgegeven op het Internet voor evaluatie en feedback),
• ontwikkelingsfase (fase waarin de ontwikkeling van een programma plaatsvindt), • adoptiefase (de fase waarin adoptie van een Open Source programma plaats vindt). In deze paragraaf zal gesproken worden over een Open Source project wanneer het gaat over de ontwikkeling van Open Source software. Een Open Source project wordt gedefinieerd als “elke groep mensen die software ontwikkelen en het resultaat vrijgeven onder een Open Source licentie” (Evers, 2000).
Figuur 5-1: Fasen in Open Source productontwikkeling
5.2.1
Ideegeneratie fase
Anders dan in de commerciële wereld wordt de ontwikkeling van een Open Source product meestal niet getriggerd door commerciële belangen5. Daar waar ondernemingen trachten marktaandeel te vergroten door in klantwensen te voorzien teneinde winst te genereren wordt de ontwikkeling van Open Source initiatieven intrinsiek getriggerd.
Een Open Source initiatief vindt zijn oorsprong veelal bij een individu of groep (vrienden/hobbyisten/onderneming) die geconfronteerd wordt met een probleem waarvoor bestaande software geen oplossingen biedt (Raymond, 2000a). De initiatiefnemer, die veelal projectleider wordt, hoeft niet in staat te zijn exceptioneel briljante code te ontwikkelen, maar het is daarentegen kritiek dat de hij/zij in staat is goede ideeën en ontwerpen van anderen te herkennen en accepteren (Raymond, 2000a), omdat aan de ontwikkeling van Open Source software vaak grote hoeveelheden ontwikkelaars bijdragen.
De meeste programmeurs zullen in de huidige stand van de techniek op zoek gaan naar een
5 Tegenwoordig zijn er steeds meer ondernemingen die businessmodellen hebben ontwikkeld waarmee geld verdiend wordt door het weggeven van software en het verkopen complementaire services/producten.
Open Source ontwikkelingsproces
oplossing die in de buurt komt van hetgeen zij wensen, om op voort te ontwikkelen (Raymond, 2000a). Met andere woorden, men probeert het wiel niet opnieuw uit te vinden. Het individu of de groep start met het ontwikkelen van een ‘solide’ basis voor het programma, al dan niet vanuit bestaande code. Deze ‘solide basis’ is essentieel voor het slagen van projecten die ontwikkeld worden volgens het Open Source paradigma, het moet namelijk in staat zijn om in de volgende fase potentiële ontwikkelaars over te halen bij te dragen. Het moet daarvoor de belofte hebben dat het kan uitgroeien tot iets moois. Zolang deze belofte plausibel is hoeft de basis niet correct te functioneren.
5.2.2
Evaluatiefase
Zodra de initiatiefnemer(s) de basis solide en de belofte plausibel acht wordt het resultaat vrijgegeven op het internet in nieuwsgroepen, mailinglists en/of mogelijk op een website die voor het project opgezet is. Op deze wijze kan het project door de gehele OS-ontwikkelgemeenschap en ook de hele wereld, worden geëvalueerd. De feedback die volgt wordt verwerkt en het resultaat opnieuw vrijgegeven, steeds in kort opeenvolgende iteraties. Op deze wijze verspreidt het project zich in hoog tempo en wanneer anderen zich in het probleem vinden trekt het geïnteresseerden aan (Raymond, 2000a). Het project groeit en krijgt vaart, het frequente vrijgeven van de ontwikkelingen leidt tot snelle fout (bug-) correcties en genereert een stroom aan feedback die de code doet verbeteren en het inzicht in het achterliggende probleem doet groeien (Bonaccorsi en Rossi, 2003).
5.2.3
Ontwikkelingsfase
Wanneer een Open Source initiatief aanhang krijgt doordat anderen zich in het probleem herkennen, dan wel interesseren, groeit het uit tot een project. De geleverde bijdrage is niet meer slechts feedback, maar tevens ook de ontwikkeling van code. De omvang die de groep krijgt brengt een grote mate van heterogeniteit met zich mee op het gebied van kennis, interesse en behoefte (Bonaccorsi en Rossi, 2003). Deze heterogeniteit zal zijn weerslag hebben op het oorspronkelijke doel van het project en het doen evolueren tot een project dat de behoeften vervult van (al) haar ontwikkelaars. De openheid en heterogeniteit in Open Source projecten hebben een positief effect op het innovatieve vermogen van het project. Zoals onder andere Daghfous (2004) stelt, zijn diversiteit en openheid belangrijke aspecten voor een innovatie. Gebruikers van de data-analyse en visualisatie tool MATLAP, geven unaniem aan dat innovatie voornamelijk en meest constructief plaats vindt in het open gedeelte van de tool, waar een grote groep ontwikkelaars in een gevarieerde samenstelling kunnen spelen met, en kunnen aanpassen van, een idee (Raymond, 2000a).
Iedereen is vrij in het gebruik van de broncode van het project, dan wel om bij te dragen, dan wel om te gebruiken voor geheel andere doeleinden. Hier varieert de ontwikkelmethode van Open Source software sterk van de traditionele methode van (software) ontwikkeling. De traditionele methode stelt gebruikers zo min mogelijk bloot aan fouten waardoor de perioden van vrijgeven langer uit elkaar liggen. In deze tussenliggende perioden wordt hard gewerkt zoveel mogelijk fouten op te sporen en op te lossen. In de Open Source wereld is dit tegenovergesteld, hier geldt het motto: geef vroeg vrij, geef vaak vrij en luister naar je gebruikers (Bonaccorsi en Rossi 2003).
5.2.4
Adoptiefase
producten zijn bijvoorbeeld kleding, een auto, een huis.
Diffusie is het proces waarbij een product wordt vervangen door iets nieuws. Met andere woorden: adoptie van een product geeft aanleiding tot het proces van diffusie. (Baker en Hart). Volgens Rogers (1995, in Baker & Hart, 1999) zijn er vier elementen van belang bij het diffusie proces:
• de innovatie zelf;
• de communicatie over de innovatie van de ene naar de andere persoon; • het relevante sociale systeem waar de personen deel van uitmaken; • tijd.
Vaak is technologische discontinuïteit de oorzaak voor het ontstaan van nieuwe technologie (innovaties), de verspreiding in het systeem (de adoptie van de innovatie in het systeem) hangt af van incrementele veranderingen (verbeteringen) die op zichzelf minder technologisch van aard zijn (Bonaccorsi en Rossi 2003).. Hierin ligt ook het probleem van de methode van Open Source softwareontwikkeling (Bonaccorsi en Rossi 2003). Zoals reeds vermeld ontstaat een initiatief door een technologische discontinuïteit (een subjectief probleem in het geval van OSS), zoals later blijkt zijn ontwikkelaars in de Open Source wereld voornamelijk artistiek en intellectueel gedreven en daardoor voornamelijk geïnteresseerd in het oplossen van de technologische discontinuïteit en niet in de incrementele verbetering van een oplossing. Hierdoor verloopt de adoptie in het systeem traag. Met andere woorden: ontwikkelaars van Open Source software doen graag artistiek of intellectueel uitdagende werkzaamheden en zijn niet geïnteresseerd in de werkzaamheden die leiden tot systeemwijde adoptie. Uitgangsgedachte hierbij is dat voor systeemwijde adoptie een zekere nuance in de innovatie moet worden aangebracht, bij software is dit voornamelijk de gebruikersvriendelijkheid.
Hybride businessmodellen lijken hier uitkomst te bieden. Door de groeiende belangstelling voor Open Source software zijn commerciële bedrijven geïnteresseerd geraakt in dit fenomeen. Omdat inkomsten door Open Source software niet via licenties mogelijk is hebben enkele bedrijven hybride businessmodellen ontwikkeld waarin zij de software weggeven en inkomsten genereren door service, consultatie, verpakking, onderhoud, training, aanpassing aan specifieke klantwensen of het verkopen van overeenkomstige hardware. Op deze wijze spelen commerciële organisaties een belangrijke rol in het adoptie proces van Open Source software (en de diffusie van ‘gevestigde’ software). Zij verzekeren adopters een breed scala aan services en beschikken over financiële middelen waarmee ontwikkelaars extrinsiek kunnen worden gemotiveerd de minder artistieke, incrementele ontwikkelingen uit te voeren (Bonaccorsi en Rossi 2003). Met andere woorden, zij kunnen ontwikkelaars betalen minder uitdagend werk te doen, werk dat geen intellectuele, dan wel artistieke gratificatie geeft. Wanneer er commerciële belangen spelen in Open Source software lijkt het voortbestaan van dergelijke software zekerder en wordt de adoptie ervan als minder risicovol ervaren.
Veel literatuur stelt dat de diffusie van informatie onderhevig is aan twee factoren: winststijging voor de aanbieder en ‘network externality’-effecten (waarde stijging voor de gebruikers). Een externality doet zich voor als een beslissing invloed heeft op alle stakeholders en niet alleen op de beslisser6. Het ‘network externality’-effect betekent dat de prestatie van een product alsmede het nut, stijgt naarmate het aantal gebruikers stijgt (Lioubareva 2005). Externalities kunnen direct, indirect of afkomstig van aanvullende diensten zijn. Softwaregebruikers worden vooral beïnvloed door directe externalities, een goed voorbeeld hiervan is de uitwisseling van bestanden. Wanneer meerdere mensen van dezelfde programma’s gebruik maken wordt de
6 http://en.wikipedia.org/wiki/Externality
uitwisseling van bestanden gemakkelijker en zal het gebruik van een dergelijk programma van meer waarde zijn voor de (Bonaccorsi en Rossi 2003). In het vervolg van deze scriptie wordt gesproken over netwerkeffect.
Volgens analyse van Brian Arthur en Paul David (in Bonaccorsi en Rossi 2003) naar diffusie is dit fenomeen onderhevig aan lock-in. Lock-in is de situatie waarin een consument afhankelijk is van een bepaalde aanbieder van producten en niet kan overstappen op een andere aanbieder zonder substantiële kosten (switching costs). In de computerindustrie heeft het lock-in effect veelal betrekking op de ontbrekende compatibiliteit tussen verschillende systemen.7
Het lock-in mechanisme lijkt een logische uitkomst van de het netwerkeffect (Bonaccorsi en Rossi 2003) en verklaart ook de waarde stijging voor de aanbieder, namelijk: wanneer de massa gebruik maakt van een bepaald softwarepakket wordt de afhankelijkheid van dat pakket voor de individuele gebruiker groter. Overstappen op een ander pakket zal gevolgen met zich meebrengen die niet gemakkelijk zijn te overzien en de kans dat men overstap op een ander systeem is dan ook vrij klein.
Ik heb dit probleem persoonlijk ervaren toen ik ervoor koos gebruik te maken van het Open Source alternatief voor het veelgebruikte Office-pakket van Microsoft. Bestandsuitwisseling tussen beide pakketen bleek niet geheel probleemloos. Bij het werken in groepsverband was ik daardoor genoodzaakt het commerciële pakket te gebruiken.
Volgens Bonaccorsi en Rossi treedt een vicieuze cirkel in werking wanneer een softwarepakket voldoende marktaandeel heeft verworven, het pakket zal nog meer gebruikt worden, waardoor er meer additionele applicaties voor zullen worden geschreven tot het pakket de markt uiteindelijk zal domineren, en dus winst biedt aan de aanbieder van de software.
Dalle en Jullien (1999) refereren aan lokale condities om uit te leggen hoe het Open Source besturingssysteem Linux zich verspreidt. Volgens hen gaat het niet zozeer om welk systeem de massa gebruikt, maar welk systeem gebruikt wordt in de directe omgeving van de beslisser. Dit is wat Rogers (1995, in Baker & Hart, 1999) “het relevante sociale systeem” van de persoon in kwestie noemt.
Volgens Lioubareva (2005) draagt ook de reputatie van de ontwikkelaars bij aan het diffusieproces. Als er veel bekwame ontwikkelaars verbonden zijn aan een project wordt deze geïnterpreteerd als kwalitatief hoogwaardig waardoor gebruikers dit project boven een ander zullen verkiezen (adoptie van dit pakket).
Een sterk voorkomend fenomeen in de Open Source wereld is het propageren van de software door haar gebruikers (Pavlicek, 1999). Dit levert een soort intieme marketing op waarbij gebruikers hun directe omgeving aanmoedigen ook gebruik te maken van Open Source software. De “communicatie over de innovatie tussen personen” volgens Rogers (1995, in Baker & Hart, 1999). Eerlijkheidshalve ben ik hier zelf, onbewust, ook schuldig aan. Witt (1997) heeft het hierbij over diffusion agents, die niet alleen verantwoordelijk zijn voor het verspreiden van de software door het te gebruiken, maar ook trachten anderen hiertoe over te halen.
Een individu of kleine groep lijkt dus in staat tot het initiëren van een initiatief dat kan uitgroeien tot een wereldwijd succes. Het Linux besturingssysteem is hiervan een goed voorbeeld. Dit is precies wat Hardin (1982) heeft aangetoond: een kleine groep (sterk geïnteresseerde) talentvolle programmeurs kan in staat zijn tot het ontwikkelen van de basis van software dat door hun gedrevenheid kan uitgroeien tot een succesvol project. Dit verklaart echter niet waarom zo velen ervoor kiezen vrijwillig bij te dragen. Hiervoor lijkt de Critical Mass-theorie bruikbaar (Bonaccorsi en Rossi, 2003). Critical Mass stelt dat wanneer sterk geïnteresseerde individuen de nodige voorwaarden scheppen voor de ontwikkeling van een goed het gemakkelijker wordt voor anderen een bijdrage te leveren. Zij werken als eerst samen en dragen zorg voor de moeilijke
initiatie van een project. In termen van Open Source betreft het hier het individu of de groep met het subjectieve probleem waarvoor een eerste aanzet voor de oplossing wordt gemaakt. Huberman (1999) heeft aan de hand van een simulatie waarin hij de diffusie van twee concurrerende technologieën analyseert geconstateerd dat wanneer een kleine groep individuen, in relatie tot de rest van de groep, dubbel gedreven is tot innoveren, Critical Mass vrijwel direct is bereikt.
5.3
Open Source: de organisatie
In deze paragraaf wordt de organisatie van Open Source software ontwikkeling beschreven. Hierbij wordt gebruik gemaakt van het 7-S model van McKinsey.
5.3.1
Strategie
Strategie heeft te maken met de doelen die een organisatie nastreeft en de manier waarop men die probeert te bereiken. Open Source initiatieven hebben niet altijd betrekking op een organisatie. Sommige initiatieven, zo niet de meeste, bestaan uit een (grote) groep vrijwilligers die een gezamenlijk doel nastreven: een programma dat werkt, dat hun probleem oplost.
Strategie heeft echter in bedrijfskundige termen betrekking op de langere termijn, wat wil een organisatie bereiken in de toekomst, hoe gaat ze daar komen?!
In die zin kan het licentiemodel van Open Source software worden gezien als een instrument om een lange termijn streven te bereiken, namelijk openheid. Open Source software is ontstaan uit een soort frustratie over het commerciële model van software(ontwikkeling). Open Source software was het antwoord op, een soort verzet tegen, het sluiten van code en de bijkomstige afhankelijkheid en vrijheidsbeperking bij het oplossen van problemen. Om op de lange termijn te waarborgen dat Open Source software open blijft zijn er verschillende licentiemodellen in het leven geroepen die dit waarborgen. In die zin is openheid en bijbehorende licenties een strategie. Binnen Open Source ontwikkelinitiatieven tracht men het wiel niet opnieuw uit te vinden, een strategie voor het versnellen van ontwikkelingen. Zo zoekt men bij het ontwikkelen van programma’s eerst naar bestaande programma’s die in de buurt komen van de functionaliteit die nagestreefd wordt. Dit wordt mogelijk gemaakt door de openheid van de software en het licentiemodel. Software ontwikkelt zich op deze manier snel. Hergebruik van software is daarmee een duidelijke strategie.
Omdat Open Source initiatieven het veelal opnemen tegen grote kapitaalkrachtige organisaties wordt het vrijgeven van code ook wel gebruikt om te voorkomen dat men achter raakt op marktleiders en op die manier ophoudt te bestaat (Lerner en Tirole, 2002). Dit wordt voornamelijk gedaan door kleine organisaties die toekomst zien in hun product(en) maar niet kunnen opboksen tegen de giganten. Door code ter beschikking te stellen aan de OSS-ontwikkelgemeenschap beschikken zij over een potentieel eindeloos grote groep ontwikkelaars die bijdragen aan de ontwikkeling van hun product. Hiermee zijn zij echter ook de mogelijkheid kwijt om geld ter verdienen aan de verkoop van hun code. Onder andere door deze strategie zijn hybride businessmodellen ontstaat.
Ondernemingen met een hybride businessmodel ontwikkelen Open Source software om te verdienen aan complementaire services (Lerner en Tirole, 2002).
Het hanteren van standaarden kan als strategie worden gezien. Toegankelijkheid van code wordt gewaarborgd door het licentiemodel. Maar toegang tot code alleen is niet genoeg. Wanneer iedere ontwikkelaar gebruik zou maken van een drastisch andere manier van programmeren zou code wel eens ondoorgrondelijk kunnen worden. Om dit tegen te gaan worden standaarden gehanteerd. Deze standaarden hebben betrekking op hoe code globaal dient te worden gestructureerd.
uit te voeren. De uitvoer van meerdere taken wordt bereikt door meerdere code-modules op elkaar aan te sluiten. Ook hiervoor is het gebruik van standaarden zo belangrijk. Het ontwikkelen van programma’s is dus een relatief snelle bezigheid wanneer men slechts ontbrekende functionaliteit hoeft te ontwikkelen, de rest bereikt men door gewenste functionaliteitmodules te gebruiken.
In de Open Source wereld wordt snelle ontwikkeling en nauwe aansluiting bij gebruikersbehoefte bereikt door het vroeg vrijgeven van code en het vaak vrijgeven van code. Een oneindig grote groep ontwikkelaars kan code inzien en verbeteringen voorstellen/aandragen. Bestaande software wordt daardoor steeds snel verbeterd, met relatief kleine veranderingen.
5.3.2
Structuur
Wenger en Snyder (2000) maken een onderscheid tussen vier groepsconfiguraties, te weten: informele netwerken, projectteams, formele werkgroepen en belangengemeenschappen. Alle vier hebben ze andere doelen, andere manieren van samenstelling, andere manieren van cohesie en verschillende redenen om op te houden te bestaan. In overeenstemming met wat Lioubareva (2005) stelt, kunnen OSS-ontwikkelgemeenschappen worden getypeerd als belangengemeenschappen. Een gemeenschapsconfiguratie is volgens Lioubareva een type netwerkstructuur en vind zijn bestaansrecht in de aanwezigheid van belanghebbenden. De waarde van een dergelijke gemeenschap is afhankelijk van erkenning en acceptatie ervan door de belanghebbenden (Lioubareva, 2005). Met andere woorden, een belangengemeenschap kan pas bestaan als alle leden elkaar erkennen en accepteren. Het zijn voornamelijk sociale links die een belangrijke rol spelen bij het ontstaan van regels, vertrouwen en samenwerkingsstructuren. Op de volgende pagina is een schematische weergave gegeven van de vier typen groepsconfiguraties zoals Wenger en Snyder (2000) ze onderscheiden.
Gemeenschappen, net als netwerken, zijn systemen die bestaan uit tal van knooppunten in de vorm van individuen of organisaties. Knooppunten zijn alleen van belang zolang andere knooppunten ermee willen samenwerken (Raymond, 2000a). Een ander kenmerkend aspect van de netwerkstructuur is dat het geen duidelijke grens kent tussen klant en aanbieder.
De structuur die een project, een belangengemeenschap, aanneemt hangt af van de grootte van het project maar alle projecten hebben een duidelijk hiërarchische organisatie met een gedecentraliseerde beslissingsstructuur. Opmerkelijk is dat een Open Source ontwikkelproject (vrijwel) nooit fysiek samen is. De meeste projecten komen tot stand zonder dat de ontwikkelaars elkaar ooit zien (Raymond, 2000a). Raymond (2000b) geeft een driedeling in projectgrootte en structuur van een project.
In de twee meest succesvolle en geprefereerde werkvormen wordt een project geleidt door een ‘welwillende dictator’ (Raymond, 2000b), een sterke leider die door persoonlijke interesse en toewijding belangrijke betekenis heeft voor de cohesie in een ontwikkelgroep.
In de meest simpele vorm is een project klein en werken er meerdere ontwikkelaars onder de leider. Wanneer projecten groeien, ontstaan er onder de ‘welwillende dictator’ vaak twee niveaus ontwikkelaars: gebruikers die een normale bijdrage blijven leveren (willekeurig geïnteresseerden uit de OSS-ontwikkelgemeenschap die ten minste één keer bijdragen) en medeontwikkelaars (ontwikkelaars die op vaste basis bijdragen en meer invloed hebben op het beslissingsproces). Leider van een groep medeontwikkelaar word je door verantwoordelijkheid te nemen voor een deelproject of door een hoge mate van bijdrage bij het oplossen van bugs (programmafouten). Een substantiële en continue investering van tijd en moeite in het project is dus vereist om een leider van een deelproject te kunnen worden. Hiermee wordt de onderhoudsverantwoordelijkheid genomen voor dat deelsysteem en wordt zowel de implementatie ervan als ook de interface met de rest van het systeem gecoördineerd. Grote projecten als het Linux besturingssysteem hebben bewezen te werken in deze vorm (Bonaccorsi en Rossi 2003).
