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
Afstudeerscriptie
Vorig jaar studeerde Marteniek Bierman af aan de Hogeschool Arnhem en Nijmegen (HAN) op het onderwerp Open Source. Hij belichte vooral de praktische kant van het werken met Open Source. Volgens hem zijn er geen algemene regels om met Open Source om te gaan. Wel zijn er een aantal kritische succesfactoren te onderkennen. In zijn afstudeerscriptie geeft hij aan hoe hier succesvol mee omgegaan kan worden. Ook komen daarin de onderdelen van het schema, het onderzoek waaruit het schema is voortgekomen, het achterliggende model en de methode om ermee te werken aan bod. Zijn bevindingen hebben geleid tot een methode die een handvat kan bieden aan iedereen die met Open Source aan het werk gaat, zo meent hij.
De scriptie is gratis te downloaden van de site van de Hogeschool Arnhem en Nijmegen.
Foto boekomslag
Het gebruik van open source software is populair! Steeds meer bedrijven zetten open source software in waardoor geld wordt bespaard met het ontwikkelen van kwalitatief hoge software. Tegenover deze populariteit bestaan bedreigingen zoals het juridisch aspect. Computer software is een vorm van intellectueel eigendom die onder dezelfde copyright wet valt die bescherming biedt tegen misbruik van media zoals muziek. Tegenover het misbruik van software staan ingrijpende bedrijfsrisico?s zoals het verlies van intellectueel eigendom en hoge kosten ten behoeve van herontwikkeling. Om deze bedrijfsrisico?s te elimineren is het van groot belang inzicht te hebben in de gebruikte open source software, de bijhorende licenties en eventuele licentieconflicten. Zonder gebruik te maken van licentie analyse en management tooling is het complex en tijdrovend, zo niet onmogelijk om alle licenties op elkaar af te stemmen. Op deze manier helpt deze tooling een organisatie geld te besparen met het gebruik van open source.
Het teken voor Open Source als we het over GNU GPL hebben is echter een wildebeest.
Trap niet in de val van nep open source. Zelf zou ik nooit Compiere (uit de business case in de bovengenoemde scriptie) als Open Source product selecteren, vanwege de sterk gelimiteerde toegang die tot de broncode wordt gegeven.
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.
Het is prima dat er meer en meer methodisch wordt gekeken naar de toepassing van Open Source middelen. Net als bij elke ict-selectie en implementatietrajecten moet naar organisatorische, financiele, technische etc. factoren gekeken worden. De kwaliteit van de leverende organisatie kan vergeleken worden met de kwaliteit van community (of de organisatie erachter zoals Sun bij MySQL). Financieel moet naar ondermeer de kosten van ondersteunende dienstverlening worden gekeken en technisch naar de blijvende integratie met Closed Source componenten. Alleen dan kan een weloverwogen en toekomstvaste keuze gemaakt worden. Zoals voor elk ict-middel.
Al jaren ben ik bezig met het introduceren van opensource bij de bedrijven waar ik werk. Bij mijn huidige werkgever heb ik daar niet veel moeite voor hoeven doen. Het gebruik van opensource zit hier in het bloed van de mensen. Wij gebruiken veel open source producten, zowel als re-useables tijdens het ontwikkelen als voor eind producten. De belangrijkste reden waarom wij zeer succesvol zijn in het toepassen van opensource is dat we naast het gebruik, ook veel bijdragen aan open source projecten. Onze klanten weten ons te vinden, juist omdat we heel veel met open source werken. Wij stimuleren onze mensen om zelf actief deel te nemen aan open source projecten. Daarnaast stimuleren wij ook onze klanten om nieuwe features terug te geven aan de community. Mijn moraal, wees niet bang om kennis te delen, je verliest er niets mee, je wordt er alleen maar sterker van.
Een van de belangrijke aspecten van open source software is dat deze vrijwel altijd gebaseerd is op open standaarden. Open standaarden voorkomen dat men vast komt te zitten aan leveranciers.
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.
Kies Open Source omdat het het beste product/component is en het beste aansluit bij de wensen, niet omdat het Open Source is. Openheid, kosten, flexibiliteit en transparantie zijn punten waar Open Source meestal goed scoort.
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.