Verschillen tussen OSS ontwikkeling (open ontwikkeling) en traditionele (gesloten) productontwikkeling.

1. Openheid in innovatie
Lessen uit Open Source voor nieuwe product ontwikkeling
30 november 2006 Daniël Brouwer
daniel.brouwer@gmail.com

2. Aanleiding van het onderzoek
Snelle ontwikkeling, nauwe aansluiting, hoge kwaliteit
Want:
Innovatie is duur en risicovol. 38% van productideeën
haalt de marktintroductie niet en 40% van de
geïntroduceerde producten faalt door slechte
marktaansluiting. - Tidd et al., 2001
Waarde toevoeging gebeurt vaak binnen de
organisatie waarna aansluiting wordt gezocht op de
markt. - Prahalad & Ramaswamy, 2004.
Terwijl:
Innovatiesucces voornamelijk wordt behaald door
het samen kunnen brengen van product(ie) kennis en
marktkennis. - Robberts, Baker & Hart, 2005.
Daarbij:
Zijn “Consumenten steeds beter geinformeerd,
bewuster over hun onderhandelingspositie en steeds
sneller verveeld.” - o.a. SwamiPersuad, 2003.

3. Het Theoretisch Kader

4. Het onderzoek
Open Source
software
ontwikkeling
aangrijpings-
kenmerkende
punten voor
verschillen
verandering
traditioneel New
Product
Development

5. Traditionele
ontwikkeling
vs.
Open Source
ontwikkeling
Kenmerkende verschillen tussen beide
ontwikkelmethoden

6. Verschil in proces
Open Source ontwikkelingsproces
1 Idee 2 Evaluatie 3 Ontwikkeling 4 Adoptie
NPD ontwikkelingsproces
1 Idee 3 Concept 5 Product 6 Test- 7 Markt-
Generatie ontwikkeling + ontwikkeling marketing Introductie
test + test (adoptie)
2 Screening 4 Business
analyse

7. Verschil in organisatie

8. Volledige openheid
Volledige openheid van zowel: Voorwaarden:
– het proces, • vertrouwen
– het product, • veiligheid
– (resulterende) kennis • afhankelijkheid
ten alle tijden. • ontbreken van belang bij geslotenheid
(Bakker, Kruiff, Willems & Rockwell, 2006).
Hoe:
• participatieovereenkomsten
• vertrouwensnetwerk waarin openheid
heerst
• bewustwording kracht van openheid:
private-collective innovatiemodel
(Von Hippel & Von Krogh, 2003; Von Hippel, 2005).

9. Belangengemeenschap
Organische structuur
Deelname is vrijwillig en een groep Voorwaarden:
ontbindt wanneer er geen collectief belang • overeenkomstige belangen / vrije deelname
meer is. Hierdoor is de structuur van een • lidmaatschap / invloed / collegiale macht
ontwikkelgroep organisch en (ontwikkel) • management paradox
beslissingen adhoc en bottom-up. • nadruk op professionele kennis
• kennis moet vrij kunnen ontwikkelen
Hoe:
• ruimte voor nastreven persoonlijke interesse
• structuur, doel en deelname laten ontstaan
• top mngt acceptatie van groepsvorming
• gemeenschapsraamwerk en
klantbindingsraamwerk
(Szmigin, Canning & Reppel, 2005)
• Adhocracy (Mintzberg, 1993)

10. Gift-Cultuur
Status en gezag door kunnen en geven
Status wordt bepaald door wat men kan en Voorwaarden:
wat men geeft. Het leveren van een • sociale acceptatie leiderschap
substantiële bijdrage, kennis, kunde, en • overvloed of non-excludability
handelen in belang van de groep geven de • dyadische / uitgestelde reciprociteit
leider gezag. Macht bestaat niet
Hoe:
• delen belonen / uitbannen hiërarchische
macht
• top mngt moet delen empathie en
welwillendheid uitdragen
• beoordelen op vaardigheid niet op
resultaten uit het verleden
• laat leiderschap afhangen van kennis,
kunde en een substantiële bijdrage

11. Gedecentrale ontwikkeling
Asynchrone communicatie & Delphi effect
Ontwikkelaars werken vaak fysiek Voorwaarden:
afgescheiden van elkaar aan een collectief • heterogene samenstelling
vraagstuk. Hierdoor is er weinig real-time • nadruk op lokale (heterogene) kennis:
communicatie en maken zij nuttig gebruik onafhankelijke oordelen
van het Delphi effect. • verenigingsmechanisme /
facilitaire medium
Hoe:
• decentralisatie: exploiteer diversiteit,
techniek voor simulatie/communicatie,
creëer sterke cohesie
• asynch. comm & Delphi effect:
versnellingskamer, virtuele werkplekken,
ideeën databank

12. Intrinsieke motivatie
Collegiale macht (i.e. onderlinge Voorwaarden:
aansturing ipv topmacht) en de vrije • keuze moet zelf genomen worden
aansluiting door interesse hebben ten • weigeren / stoppen is een optie
gevolg dat ontwikkelaars intrinsiek • proces dat blijft stimuleren/belonen
gemotiveerd zijn en intrinsiek beloond • organisationele middelen: ruimte en
worden. middelen
Hoe:
• belangengemeenschappen
• vrijelijk toegankelijke ideeën database
• individuele beloning door erkenning
• afwijkend gedrag / creativiteit stimuleren

13. Incrementele verandering
continue multidimensionele feedback
Ontwikkelstappen zijn kort en gates zijn Voorwaarden:
extern. Waardoor na elke stap opnieuw • betrokkenheid markt
marktintroductie plaats vindt. Dit heeft tot • volledige openheid
continue, multidimensionele feedback en • korte ontwikkeliteraties:
evolutionaire ontwikkeling tot gevolg. nadruk op verbetering ipv perfectie
• heterogene feedbackpoule
• facilitaire medium
• centraal te testen, of non-excludability
product
Hoe:
• Belangengemeenschap
• Klantbindingsraamwerk en
gemeenschapsraamwerk.

14. Passieve coördinatie
mechanismen
Vooraf vindt standaardisatie van Voorwaarden:
vaardigheden plaats, daarna is onderlinge • zelfsturende groep (autonomie)
afstemming door korte ontwikkeliteraties • radicale kenniswerkers (professionals)
en feedbackverwerking het primaire • korte ontwikkel en feedback iteraties:
coördinatie mechanisme. incrementele verandering
Hoe:
• standaardisatie van vaardigheden
• standaardisatie van normen en waarden
• autonomie van ontwikkelaars
• verantwoordelijkheid bij ontwikkelaars

15. Hergebruik
Interne en externe bronnen
Open Source ontwikkelgemeenschappen Voorwaarden:
kunnen vrij uit zowel interne als externe • openheid
bronnen putten. • vrijheid
• beschikbaarheid
• vertrouwen
• absorptive capacity
• mechanisme dat vrijhergebruik waarborgt
Hoe:
• positionering in kennisnetwerk /
vertrouwensnetwerk
• absorptive capacity verbeteren

16. Klant als ontwikkelaar
Klanten zijn zowel ontwikkelaar als Voorwaarden:
gebruiker in Open Source. Men draagt (af • lage toetredingsdrempels
en toe) bij, geeft feedback, of past een • collectieve ontwikkelmethodiek
product aan naar eigenwens, al dan niet
Nuttig wanneer:
voor eigen gebruik.
• Krimpend marktsegment en hoge klanteisen
• Klachten ontwikkeltijd
• Flexibel productie systeem
Hoe:
• Gebruiker-toolkits
(Thomke & Von Hipple, 2002).

17. Toetsing: reacties uit praktijk

18. Insteek toetsing
• Hoe fundamenteel is het verschil?
• Praktisch toepasbaar?
Getoetst bij:
KPN Internet
KPN Business Consulting
Uitgever ThiemeMeulenhoff

19. Kenmerken van Open Source lijken moeilijk toepasbaar in branches waar
technische ontwikkelingen worden gedaan met een hoge investering.
Kenmerken van Open Source lijken echter zeer goed toepasbaar in de media en
uitgevers branche.
• Iedere uitgever ontwikkeld haar eigen content. Voor de klant is vaak alleen de
presentatie ervan onderscheidend.
• Klanten ontwikkelen zelf steeds meer content (docenten, weblogs, podcasts e.d.)
• Informatie is non-excludable
• Bij auteurs is hergebruik met bronvermelding gebruikelijk
• Auteurs kunnen weinig macht uitoefenen maar hebben gezag door reputatie
• Auteurs werken gedecentraliseerd, zijn (veelal) intrinsiek gemotiveerd en hebben
grote mate van autonomie
Toekomstscenario:
• Een informatieruimte waarin vrijelijk gedeeld en ontwikkeld wordt.
De rol van de uitgever is selectie/screening en toegang tot deze ruimte
verschaffen.

20. The big lesson learned
Open Source blijkt lastig !

21. Discussie
• Asychrone communicatie
• Gift Cultuur: geen macht maar gezag
• Marktgestuurde incrementele verandering:
– Branche en product
• Inter of intra organisationeel
• Toegepast: vertical Media