outsourcing / Opinie
Succesvol omgaan met Open Source
Open Source is ‘serious business' aan het worden. Voor Marteniek Bierman reden om zijn studie aan de Hogeschool Arnhem en Nijmegen (HAN) af te ronden met de scriptie ‘Werken met Open Source'. Hij belicht daarin vooral de praktische kant van het werken met Open Source. In dit artikel geeft hij aan hoe je moet omgaan met kritische succesfactoren.
Open Source heeft zich de afgelopen jaren tot een wijd verbreid, maar ook enigszins ondoorzichtig begrip ontwikkelt. Een goede definitie van het begrip is dan ook wenselijk, zodat iedereen snapt waar het over gaat. De vertaling van de term ‘Open Source' geeft wat houvast. ‘Open' wordt in de Nederlandse vertaling geïnterpreteerd als toegankelijk of transparant, zoals een open deur, open verslaglegging of een open brief. ‘Source' is de term voor bron en wordt gebruikt in het woord "broncode". Het is het deel waaraan door programmeurs in een taal als bijvoorbeeld C, C# of Java gewerkt wordt. De broncode is de drager van het idee achter de software (belangrijk voor kwesties over intellectueel eigendomsrecht). De mate van openheid van de broncode wordt vastgelegd in de licentie.
Veel rond Open Source draait om het vrije gebruik ervan en de voorwaarden die daaraan gesteld zijn. Het is daarom belangrijk om te begrijpen dat deze voorwaarden per licentie kan verschillen. In de licentie wordt bijvoorbeeld bepaald of, en in hoeverre, aangebrachte wijzigingen in de code openbaar gemaakt moeten worden. Verder worden er zaken in geregeld om te voorkomen dat iemand bepaalde broncode plotseling tot eigendom verklaard en daarmee (financiële) rechten gaat claimen op iets dat voor algemeen gebruik bedoeld is. Daarom is kennis van de licentie en de strekking ervan belangrijk.
Meer dingen om op te letten
Behalve de genoemde licenties zijn ook andere dingen van belang om in de gaten te houden. Zo spelen Open Source communities bijvoorbeeld een belangrijke rol. Wordt de rol van gebruiker, of van aanbieder (of beide) vervuld? Wettelijke en politieke omstandigheden hebben hun invloed en zo zijn er meer zaken te benoemen. Voor het slagen van Open Source projecten is het essentieel om voldoende kennis te hebben over dit soort zaken. Veelal moet deze kennis zelfs verworven zijn nog voordat het project van start gaat. Dit soort dingen zijn de kritische succesfactoren van een Open Source project. De genoemde kennis is ook niet statisch. In de loop van een project wordt deze kennis bijgehouden, maar ook breder en dieper gemaakt. Deze kennis wordt ook weer doorgegeven. Hierdoor kunnen anderen er op hun beurt profijt van hebben. Feitelijk slaan de kritische succesfactoren op het omgaan met kennis over Open Source (producten). Een dynamisch geheel dus. Om dit werkbaar te maken is er een schema opgesteld. Dit schema is zodanig opgesteld dat er afgelezen kan worden, wie voor welke kennis moet zorgen, wanneer dit moet gebeuren en waar deze kennis te halen, of te brengen is.Thema's, Factoren en Platforms
Het schema is allereerst geordend aan de hand van thema's, onderwerpen die, op bepaalde tijdstippen, in Open Source projecten een rol spelen. In de eerste plaats het thema ‘beschikbaarheid'. Nadruk ligt hier op het beschikbaar zijn van het systeem zelf, en beschikbaarheid van informatie over het systeem. Het gaat over wat het desbetreffende systeem kan. Daarnaast het thema ‘toegankelijkheid'. Hierbij ligt de nadruk op het inzicht in de binnenkant van het systeem. De benadering is hier technischer van aard, over hoe het desbetreffende systeem werkt. Tot slot het thema ‘continuïteit'.
Hierbij is inzicht in de mensen die invloed hebben op het systeem het belangrijkste. Het gaat hier vooral om de organisatorische omgeving, over wie er met het systeem te maken hebben. Het schema laat ook zien welke kritische succesfactoren er zijn en hoe deze zich verhouden tot de thema's. Niet alle factoren spelen tegelijkertijd een rol.
Daarnaast gaat iedere factor over een ander soort kennis. Ook geeft het schema aan op welke plekken bepaalde soorten kennis zich bevindt. Hierdoor is het makkelijker geworden om gericht naar een stuk kennis op zoek te gaan.
Aanbieders en gebruikers
Uit het schema wordt duidelijk dat er verschillende rollen vervuld kunnen worden. Aanbieders zijn degenen die Open Source ontwikkelen en ter beschikking stellen. Aanbieders werken meestal vanuit eigen initiatief, maar ook commerciële motivatie neemt de laatste jaren toe. Gebruikers zijn degenen die Open Source inzetten voor eigen gebruik, of bij ondersteuning van een (hun) organisatie. Voor veel gebruikers is het kostenaspect belangrijk, maar zeker ook de beschikbaarheid van de code. Er ontstaan ook combinaties van gebruikers en aanbieders. Een organisatie kan bijvoorbeeld eerst opdracht geven om een nieuw systeem te ontwikkelen. Vervolgens kan deze organisatie het ontwikkelde systeem als Open Source aanbieden.Gebruik van het schema
Het schema kan worden gebruikt als checklist. Er zit echter ook een methode achter. Deze methode bestaat uit het volgen van een aantal opeenvolgende stappen. Eerst wordt gekeken naar het thema dat speelt. Vervolgens kan er afgeleid worden welke kritische succesfactor er geldt. De rol (aanbieder of gebruiker) wordt dan bepaald en hierdoor wordt duidelijk hoe de factor geborgd kan worden. Tevens wordt duidelijk welk platform hiervoor gebruikt kan worden. Niet alle kritische succesfactoren zijn op hetzelfde moment van belang. Aan het begin van het project zal er meer aandacht zijn voor het thema beschikbaarheid. Later verschuift de aandacht naar de andere thema's. Het is van groot belang om steeds te blijven kijken of alle(!) succesfactoren nog wel voldoende geborgd zijn.
Ook blijken sommige thema's in een later stadium van een project weer terug te komen. Het zwaartepunt van de aandacht verschuift dus over de verschillende fasen van het project heen en weer. Er is al eerder opgemerkt dat zowel de aanbieder als de gebruiker, op verschillende tijdstippen, informatie van het platform ophalen of er op zetten.
Voldoende geborgd?
Bij het toepassen van de methode komt de vraag naar voren wanneer een kritische succesfactor voldoende geborgd is. Om hier aan tegemoet te komen is de ‘borgingspiramide' opgesteld. Deze borgingspiramide geeft enig houvast om te kunnen bepalen of er voldoende kennis verworven is om een factor als voldoende geborgd te kunnen beschouwen. De eerste stap vergt weinig inspanning. Naarmate de top meer in zicht komt, kost het steeds meer moeite om de benodigde kennis te verwerven en te behouden.
De basis van de piramide wordt bereikt als er voldoende kennis aanwezig is voor het begrijpen van de desbetreffende factor. Het is bekend waar het over gaat, maar ook niet meer dan dat. De volgende trede geeft aan dat er voldoende kennis over de factor aanwezig is om er een (zinnige) discussie over te kunnen voeren. Daaropvolgend zou er voldoende kennis moeten zijn om een advies te kunnen geven. Hier wordt dus nog geen verantwoordelijkheid genomen. Met de volgende stap, het kunnen nemen van operationele beslissingen, wordt er wel verantwoordelijkheid genomen. Is er voldoende kennis verworven om er strategische beslissingen mee te (durven) nemen, dan is de top bereikt. De mate van borging hangt dus samen met de tijd die er voor het verwerven van kennis nodig is. Hier wordt dus ook duidelijk dat, hoe serieuzer een project is, hoe meer tijd er in het verwerven van de benodigde kennis gestoken moet worden. Als er (slechts) een verkenning van beschikbare pakketten uitgevoerd wordt, is het voldoende om de factoren tot het niveau van advies te borgen. Om uiteindelijk een pakket te kiezen is borging tot het niveau van strategische beslissing weer noodzakelijk. Dit is overigens niet het exclusieve domein van Open Source projecten. Ook andere projecten hebben met dergelijke borgingsniveaus te maken.
Handgrepen
Een aantal kritische succesfactoren voor het werken met Open Source is naar voren gehaald en er is samenhang aangebracht. Tevens is aangegeven hoe deze factoren zich verhouden tot de rest van de (project) omgeving. De bedoeling is om handgrepen te creëren waarmee mensen, die in de praktijk met Open Source (gaan) werken, uit de voeten kunnen. Het is van belang om te beseffen dat Open Source een uitgestrekt en dynamisch geheel is, dat per dag kan veranderen (en dat ook doet!). Hierdoor is het onmogelijk om Open Source volledig te doorgronden, laat staan beschrijven. Het is wel mogelijk om er een interessant onderdeel uit te halen en dat te exploreren. Open Source is ‘serious business' aan het worden. Het wordt tijd om meer onderdelen van Open Source (verder) te exploreren. Hierdoor kan ieder, die er het belang van inziet, er op een succesvolle manier mee leren omgaan.Marteniek Bierman, projectmanager bij Topicus
De scriptie is gratis te downloaden van de site van de Hogeschool Arnhem en Nijmegen.
Foto boekomslag
Open source kan in mijn ogen alleen succesvol worden als de goede naam ervan niet vertroebeld wordt door halfslachtige leveranciers. Zodra je voor een 'Professional'- of 'Enterprise'-editie, of voor welke andere vorm van pakketuitbreiding dan ook, moet gaan betalen, werpt dit voor veel potentiele gebruikers een drempel op. Dit is jammer, want de naam van Open Source wordt in dit geval alleen gebruikt door leveranciers om een voet tussen de deur te krijgen.
De meeste leveranciers kunnen of willen hun software niet aanpassen of koppelen aan specifieke software van anderen. Vaak wordt dan weer een extra onderdeel van een bedrijfseigen suite aangeboden om het gat te dichten. Uiteindelijk zijn dan gelijkwaardige suites van verschillende leveranciers in gebruik. Dit maakt het software landschap en het beheer complexer dan nodig is.
De remedie bestaat uit het zoveel als mogelijk eisen van open standaarden voor nieuwe of te vervangen software. Neem vervolgens bij de selectie van software zowel open als closed source mee, omdat geen van beide soorten software in alle gevallen zaligmakend is. Mocht een product op termijn niet meer voldoen, dan is het te vervangen zonder al te ingrijpende gevolgen op de overige software.
Het uitgangspunt van veel organisaties is: we gaan een nieuw product kiezen en willen daarbij ook Open Source betrekken. Elementen waarop gelet moet worden bij de keuze van Open Source zijn binnen organisaties vaak (nog) niet duidelijk. Het schema van Marteniek kan hierbij helpen. Hoewel het overlap heeft met de selectie van software in z?n algemeenheid, biedt dit schema een aantal onderdelen die specifiek voor Open Source van belang zijn.
Dit schema is dus een prima aanvulling op de wijze waarop software (tot nu toe meestal closed source) geselecteerd kan worden.
- 10:41 Xerox pakt printkosten RIVM aan
- 10:35 'Het gaat hier in Roemenië razendsnel'
- 16:52 Schiphol reorganiseert ook ICT-afdeling
- 10:31 ING gunt Atos Origin opslagdiensten
- 16:28 Nedfield kan financiële afspraken niet nakomen
- 12:38 Gaat het bij IT-outsourcing wel om IT?
- 10:45 BMC levert beheersoftware aan KBC Groep
- 11:10 Werkplekbeheer NXP gaat naar Atos Origin
- 11:40 VCD regelt facturatie Medisch Spectrum Twente
- 14:39 Capgemini regelt werkplekbeheer voor LNV
Profiteer van managed hosting
Bij managed hosting wordt ICT vanuit een datacenter aangeboden. Deze vorm van outsourcing richt zich......
Computable Events - Outsourcing
Computable organiseert verschillende events met praktijkgerichte informatie over actuele onderwerpen in de ICT:
Alfa Accountants & Adviseurs richt op kernactiviteiten en bespaart op ICT-kosten
16-07 11:04 Alfa Accountants en Adviseurs is een adviesorganisatie voor het midden- en kleinbedrijf op het terrein van accountancy, belastingen, bedrijfskundige zaken en wat daarmee verband...
Outsourcing praktijk'Het gaat hier in Roemenië razendsnel'
02-07 10:35 In de Roemeense universiteitsstad Cluj blijft van de bekende vooroordelen over het Oost-Europese land weinig over. Modieus geklede mensen struinen langs gezellige terrasjes in de...
Outsourcing achtergrondGaat het bij IT-outsourcing wel om IT?
29-06 12:38 Als het om “harde” it gaat zoals apparatuur, infrastructuur of werkplekken is outsourcing inmiddels goed te organiseren. Regievoering en leveranciersmanagement bevinden zich...
Outsourcing opinie


