Development

Software-ontwikkeling

Voordelen inner source

30 oktober 2014

Open source is tegenwoordig wijdverspreid en geaccepteerd in de software-industrie, bijvoorbeeld door gebruik van open-sourceontwikkeltools of open-sourcedesktopapplicaties. Een nieuwere ontwikkeling is ‘inner source’, wat refereert aan het gebruik van open-sourceontwikkelpraktijken binnen de muren van een organisatie. Met inner source kunnen ontwikkelaars zelf een intern open-sourceproject starten, waaraan anderen vrijwillig kunnen bijdragen. Het grote verschil met ‘echte’ open source is dat de broncode niet openbaar wordt gemaakt buiten de organisatie. Er is dan ook geen open-sourcelicentie verbonden aan deze software. Zeker in grote organisaties met tal van softwareontwikkelteams, is duplicatie van software niet ongewoon. In zulke gevallen kan het interessant zijn om een inner-sourceplatform beschikbaar te maken om ontwikkelaars zelf samenwerkingsinitiatieven te laten nemen. Inner source heeft tal van potentiële voordelen:

  • Meer softwarehergebruik: doordat meer ontwikkelaars op de hoogte zijn van allerlei initiatieven binnen de organisatie, kunnen zij bijdragen aan bestaande softwarecomponenten in plaats van het zelf te ontwikkelen.
  • Verbetering van softwarekwaliteit: net als in open-sourceprojecten geldt het motto van Linus’s Law: ‘Given enough eyeballs, all bugs are shallow’, ofwel: er is altijd wel iemand die inzicht heeft hoe een bepaald defect kan worden opgelost.
  • Open innovatie: door meer mensen uit de gehele organisatie te betrekken bij een softwareproject, kunnen projecten profiteren van de expertise die vaak wél beschikbaar is in de organisatie, maar door organisatorische barrières vaak niet bekend is bij anderen.
  • Kortere marktintroductietijd: de tijdsduur die nodig is kan mogelijk verkort worden door grootschalige deelname in een inner-sourceproject.
  • Betere interne mobiliteit van ontwikkelaars: naarmate ontwikkelaars bekend raken met verschillende inner-sourceprojecten worden zij makkelijker inzetbaar in andere projecten. Bovendien biedt een inner-sourceplatform een standaardontwikkelomgeving en tools, zodat ontwikkelaars bekend raken met deze tools.

Drie categorieën

Tal van organisaties hebben inner-source-initiatieven opgezet in de loop der jaren: dicht bij huis vinden we ze bij Philips, maar er zijn vele andere bekende namen: Adobe, Ericsson, General Electric, Hewlett-Packard, IBM, Lucent (voor de fusie met Alcatel), Nokia (voor de overname door Microsoft), SAP, Samsung, Siemens en zelfs het Department of Defense in de VS.

Verschillende open-sourceprojecten hebben verschillende processen en gewoontes, en het is niet mogelijk om van ‘de’ open-source-aanpak te spreken. Er zijn echter wel een aantal overeenkomsten te vinden (zie kader). Zoals gezegd zijn er tal van organisaties geïnteresseerd in een open-sourcewerkwijze, maar het is niet altijd duidelijk hoe een organisatie daarmee kan beginnen. Wat volgt zijn negen aandachtspunten voor het implementeren van een inner-source-aanpak, gegroepeerd in drie categorieën: product, proces & tools en organisatie & cultuur.

• Zorg voor een initieel softwareproduct met verschillende stakeholders en modulaire architectuur om deelname te stimuleren.

1. Initieel product
Allereerst kan een inner-sourceproject niet beginnen ‘from scratch’: er moet een initieel product zijn dat andere ontwikkelaars kunnen gebruiken. Zodra er een initieel product is dat andere ontwikkelaars kan aantrekken, kan een gemeenschap zich vormen rondom dat product.

2. Stakeholders
Een inner-sourceproject werkt het beste als er verschillende stakeholders zijn, die verschillende eisen stellen aan de software, en verschillende expertise hebben. Als een softwareproject alleen maar ontwikkelaars van een enkel team aantrekt, dan heeft het weinig zin om de ontwikkeling open te stellen, en is de kans klein dat anderen zich bij de gemeenschap aansluiten.

3. Modulariteit
Een hoge graad van modulariteit is ook belangrijk voor een inner-sourceproject, net als dat ook belangrijk is voor conventionele open-sourceprojecten. Modulariteit is natuurlijk een goede eigenschap van elk softwareproduct, omdat het onderhoud van modulaire software veel makkelijker is dan van zogenaamde spaghetticode. Een modulaire architectuur in open en inner source maakt participatie veel makkelijker, omdat ontwikkelaars betekenisvol kunnen bijdragen. Ze kunnen zich bijvoorbeeld op een bepaald stuk functionaliteit richten. Bovendien voorkomt het dat verschillende ontwikkelaars in hetzelfde stuk code zitten te werken, met als gevolg ‘merge’-conflicten die handmatig moeten worden opgelost.

• Laat ontwikkelaars zelf hun proces bepalen en gebruik gemeenschappelijke tools.

1. Ontwikkelpraktijken
De wijze waarop open source wordt ontwikkeld is fundamenteel anders dan (veelal commerciële) conventionele closed-sourcesoftware. Het grootste verschil is dat bij closed-sourcesoftware normaal gesproken taken worden gegeven aan ontwikkelaars; zij werken aan bepaalde onderdelen van de software omdat de taken zo zijn verdeeld. In open source werken de meeste ontwikkelaars vrijwillig aan het project en kiezen zelf waar ze aan werken. Alhoewel steeds meer open-sourceprojecten worden gesponsord door bedrijven, bijvoorbeeld door werknemers te laten werken aan bepaalde functionaliteit, worden de meeste open-sourceprojecten toch nog steeds door vrijwilligers gedaan.

2. Kwaliteitszorg
Een ander punt waarop open en inner source verschillen van closed source is kwaliteitszorg. Waarschijnlijk het meest bekend is de zogenaamde ‘peer-review’ van bijdragen van ontwikkelaars. Een ontwikkelaar kan een contributie of een verandering in de broncode maken, wat vervolgens wordt gecontroleerd door andere ontwikkelaars. Een andere praktijk die vaak wordt gebruikt bij open-sourceprojecten is ‘release early, release often’, ofwel: vaak en regelmatig een nieuwe versie beschikbaar maken, zodat er regelmatig en snel feedback komt op nieuwe functionaliteit. Op die manier is het maken van een nieuwe versie niet langer een ‘Big Deal’, met als gevolg minder druk op releasemanagers, wat ook de kwaliteit ten goede komt.

3. Ontwikkeltools
Het is ook belangrijk dat iedereen die meewerkt toegang heeft tot dezelfde (of compatible) ontwikkeltools. In grote ondernemingen gebruiken verschillende teams vaak verschillende ontwikkelomgevingen en tools. Dit maakt het samenwerken echter heel lastig, of onmogelijk, als ontwikkelaars de software niet kunnen compileren en draaien.

• Laat ontwikkelaars zichzelf organiseren binnen een trans­parante cultuur.

1. Coördinatie en ‘meritocratic’ leiderschap
Conventionele softwareprojecten worden geleid door een projectleider, met een duidelijke hiërarchie in de organisatie. Open-sourceprojecten werken echter op basis van verdienste (‘merit’): des te meer bijdragen van hoge kwaliteit een ontwikkelaar maakt, des te meer invloed en respect hij krijgt binnen een project. Dit is belangrijk ook bij inner source omdat participatie vrijwillig is.

2. Transparantie
Transparantie is een belangrijk aspect van inner source; het ontwikkelproces van een project moet volledig zichtbaar zijn voor iedereen binnen de organisatie die wil bijdragen. Een inner-sourceplatform, zoals een interne SourceForge, is een belangrijke infrastructuur die ontwikkelaars in staat stelt om de broncode van een project te delen, te communiceren via mailing lists, en kennis te delen op interne wiki’s.

3. Steun van de organisatie en motivatie van ontwikkelaars
Het is bijzonder belangrijk dat het leiderschap van een organisatie een inner-source-initiatief steunt, bijvoorbeeld door ontwikkelaars vrij aan zulke projecten te laten werken. Des te meer mensen worden vertrouwd dat ze de juiste dingen doen, des te groter de kans dat ze daadwerkelijk productiever worden. Aan de andere kant is het ondersteunen van zulke initiatieven niet voldoende, uiteindelijk is het aan de ontwikkelaars om initiatief te nemen. Het zou volstrekt tegen de open-sourcefilosofie ingaan om participatie te verplichten.

Bazaar-stijl

Inner source is een relatief nieuwe aanpak, een vorm van ‘community-based’ softwareontwikkeling. Voor bedrijven die steeds meer afhankelijk worden van open source, is het opzetten van interne communityprojecten een goede manier om bekend te raken met deze ‘bazaar’-stijl van ontwikkelen.

Inner source

Elke organisatie implementeert inner source op een manier die past bij de bedrijfscultuur. Sony Mobile, bijvoorbeeld, is een groot bedrijf dat bestaat uit verschillende divisies in verschillende landen. De advocaten binnen het bedrijf uitten hun zorgen over het delen van code op een globale schaal. Om die reden heeft het bedrijf een interne inner-sourcelicentie, die het delen van code mogelijk maakt en de advocaten geruststelt. Een ander voorbeeld is Philips Healthcare, dat medische apparatuur zoals MRI-scanners maakt en wordt gereguleerd door de Food & Drug Administration om op de Amerikaanse markt te mogen leveren. Om die reden moet het ontwikkelproces voldoen aan de eisen die de FDA stelt. Daarom is het ontwikkelproces formeler, maar zijn er mechanismen gebaseerd op de open-sourcefilosofie, die het samenwerken aan projecten makkelijker maakt.

Open source

Er zijn talloze successvolle open-sourceproducten beschikbaar, met Linux en Apache wellicht als beste voorbeelden. Deze producten worden niet ontwikkeld via goedgedefinieerde softwareontwikkelprocessen, zoals het V-model of Scrum. In plaats daarvan wordt open source ontwikkeld via een schijnbaar ‘chaotisch’ proces. De open-source-evangelist, Eric Raymond, heeft conventionele en open source ooit vergeleken met het bouwen van respectievelijk een kathedraal en een bazaar. De conventionele aanpak is ‘top-down’, met een compleet ontwerp van tevoren uiteen­gezet alvorens aan ontwikkeling wordt begonnen. De ‘bazaar’-stijl is meer een ‘bottom-up’-proces, waarbij ontwikkelaars met verschillende interesses contributies maken. Deze metaforen zijn inmiddels wat achterhaald, maar niettemin bruikbaar om open source te karakteriseren.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Inloggen

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!