Implementatiestrategie open source software VROM (versie 0.3 waarin de resultaten van 11 maart 2009 zijn verwerkt) Inhoudsopgave 1. 2. 3. 4. 5.
Inleiding Missie & Visie Stand van zaken Strategie 2009 – 2011 Implementatie a. Activiteiten b. Besluitvorming en sturing Bijlage 1: Deelnemers strategie (uit dit document geschrapt) Bijlage 2: Beknopte samenvatting strategiemeeting 11/3/09 Bijlage 3 : Toelichting op open source software Bijlage 4 : Redenen in het algemeen voor toepassing open source software
Hoofdstuk 1 – Inleiding Actieplan NOiV De „motie Vendrik‟ resulteerde in het Actieplan Nederland Open in Verbinding (NOiV). In dit actieplan van staatssecretaris Heemskerk zijn onder andere de volgende doelstellingen opgenomen: Nederland wil op het gebied van ICT tot de koplopers in Europa behoren Het tegengaan van monopolieposities op de softwaremarkt en het voorkomen van misbruik door dergelijke economische machtsposities Bij gelijke geschiktheid heeft open source software de voorkeur Het Actieplan Nederland Open in Verbinding stelt dat alle overheden over een implementatiestrategie open source software dienen te beschikken (actielijn 7). Het programmabureau Nederland Open in Verbinding (NOiV) ondersteunt ministeries bij het ontwikkelen van deze strategie door een strategiebijeenkomst voor elk ministerie te organiseren. Onderhavig strategiedocument is het resultaat van de strategiedag d.d. 11 maart 2009. Wat is ‘open source software’? Het is software net als andere software. Op het meest basale niveau betekent de term open source software simpelweg dat de broncode van de software „open en beschikbaar‟ is. De broncode is het programma waarin de software is geschreven. Software wordt als 'open' beschouwd als de bron code gelezen en aangepast kan worden. Beschikbaarheid betekent dat iedereen de code gratis of tegen een nominaal bedrag kan verkrijgen. De definitie van het Open Source Initiative (OSI), de zogenaamde Open Source Definition (OSD), bestaat uit tien regels waar software aan moet voldoen voordat het Open Source Software (OSS) mag worden genoemd. De belangrijkste elementen uit deze definitie zijn het recht om de software zonder beperkingen te mogen distribueren en om de bron code te mogen inzien en naar eigen inzicht te mogen aanpassen (bijlage 1). Hoe verhoudt open source software zich tot maatwerksoftware en standaardsoftware? VROM beschikt over maatwerksoftware dat in opdracht (en op kosten) van VROM is/wordt ontwikkeld; de eigendomsrechten liggen bij VROM. De afgelopen jaren is er een veelheid van open source
1
functionaliteiten op internet beschikbaar gekomen zodat het de moeite loont om bij de ontwikkeling van maatwerk na te gaan of er relevante open source software functionaliteiten beschikbaar zijn die bij de ontwikkeling van dit maatwerk gebruikt kan worden. Ook kan VROM besluiten om de broncode van het maatwerk beschikbaar te stellen als open source software. Naast het maatwerk - met name op de interbestuurlijke beleidsterreinen - gebruikt VROM standaardsoftware (tegen betaling van het gebruikrecht). In toenemende mate komen open source equivalenten van standaard software beschikbaar. Deze software is de moeite van het overwegen waard zeker wanneer er voldoende ondersteuning in markt verkrijgbaar is. Daarbij zegt het kabinetsbeleid:„bij gelijke geschiktheid ‟ heeft open source software de voorkeur. Hoofdstuk 2 – Missie en Visie De missie en visie ten aanzien van open source software worden bepaald door het van oudsher gevoerde sourcingsbeleid waarbij ict dienstverlening wordt ingekocht. Primair gaat het om de dienstverlening en secundair over de software die daar bij wordt ingezet. Op basis van functionele specificaties wordt de vraag in de markt gezet en de „aansluitvoorwaarden‟ en de op Marij gebaseerde architectuur zijn daarbij leidend. Voor wat betreft de ambitie ten aanzien van open source software onderscheidt VROM: Interbestuurlijk: VROM wil hier tot de voorhoede behoren: waar open standaarden beschikbaar zijn worden deze toegepast en waar mogelijk en zinvol worden open source software componenten toegepast. interdepartementaal: VROM is volger en sluit aan bij interdepartementale ontwikkelingen en samenwerking. 'In principe' zal VROM altijd volgen, ook als de kosten en ambities hoog zijn. bedrijfsvoering: hier is sprake van historie en is VROM volger. Hoofdstuk 3 – Stand van zaken Beleid: bij de ontwikkeling van software (overwegend maatwerk) voor interbestuurlijke ontwikkelingen wordt zoveel als mogelijk „open‟ opgezet met open standaarden en waar mogelijk en zinvol open source software (componenten). Een verbeterde open source software component wordt wanneer zinvol of vereist ter beschikking gesteld aan derden. strategie is dat bij het ter beschikking stellen van verbeterde software componenten aan derden dit wordt overgelaten aan de dienstverlener. strategie is dat bij de inkoop van dienstverlening het gebruik van open source software aan de dienstverlener wordt overgelaten er vindt geen sturing op plaats (geen bewust beleid).
Feitelijk gebruik: Open source software: VROM breed: Apache (webserver), PDF creator Applicatieontwikkeling, beheer en beveiliging: o Applicatieservers; Tomcat, Jboss o Beveiliging: Iptables o Proxy server: Squid o Open source viewer IrfanView Implementatie Open standaarden: - Webrichtlijnen (W3C) - ODF: ingevoerd via een add-on iop de Mircosoft office pakketten - STUF: toepassing binnen applicaties die de gemeentelijke organisaties raken)
2
Successen en aandachtspunten tot dusver Landelijke Voorziening (LV) Basisregistratie Adressen en Gebouwen De LV BAG bevat de landelijke verzameling van alle gemeentelijke adres- en gebouwenregistraties. De LV BAG is volledig gerealiseerd met een framework van open source componenten (Java) en maakt gebruikt van open standaarden (W3C, SOAP/XML). Een kanttekening hierbij is de beheerder - het kadaster - deze toepassing niet in beheer nam zodat deze herbouwd is. LV Wet Kenbaarheid Publiekrechtelijke Beperkingen De LV BAG bevat de landelijke verzameling van alle gemeentelijke registraties omtrent publiekrechtelijke beperkingen. De LV Wkpb is volledig gerealiseerd met een framework van open source componenten (Java) en maakt gebruikt van open standaarden (W3C, SOAP/XML). Een kanttekening hierbij is dat de beheerder - het kadaster - deze toepassing niet in beheer nam zodat deze herbouwd is. Landelijke Voorziening Omgevingsvergunning De Omgevingsvergunning maakt gebruik van open standaarden en gebruikt voor delen open source ELO componenten. De voorziening is dit jaar in gebruik genomen. DURP/RO-Online RO-Online zal gebruik gaan maken van open standaarden en OSS(OpenGis en W3C). De realisatie wordt uitgevoerd in Open Source Software. De aanbieding met OSS leverde een betere Architectuur op, waardoor de realisatie- en uiteindelijke beheerkosten aanzienlijk lager uitpakte. Inmiddels wordt de ontwikkelde/verbeterde software ingezet bij provincies. GDI Rampenbestrijding en Crisisbeheersing Dit project tracht ter ondersteuning van de verschillende crisisstaven in Nederland op rijks-, provinciaal-, regionaal- en lokaal niveau belangrijke geodata/informatie beschikbaar te krijgen door services beschikbaar te stellen en een centrale GIS applicatie ter presentatie. Voor de gegevensmodellen (semantiek), uitwisselformaten en services wordt zoveel mogelijk uitgegaan van open standaarden. De presentatieapplicatie wordt als mogelijk met open source software gerealiseerd. Hoofdstuk 4 – Strategie 2009 - 2011 Werkingsgebied De ambitie ten aanzien van open source software die in hoofdstuk 2 is verwoord, geldt voor geheel VROM. De te maken keuzes bij de realisatie van de implementatiestrategie kunnen voor de verschillende organisatieonderdelen verschillen omdat deze afhankelijk zijn van de bedrijfsvoering en de aard van het primaire proces. De implementatiestrategie open source software heeft betrekking op het werkterrein van het Kerndepartement VROM Inspectie (VI) Agentschap: RijksGebouwenDienst (RGD) Planbureau voor de Leefomgeving Nederlandse Emissieautoriteit Raden en commissies Ambitie ten aanzien van open source a. Interbestuurlijke trajecten voorhoede Deze ambitie wordt zichtbaar in: - het gebruik van open standaarden - het nadrukkelijk vragen naar open source componenten in de uitvraag - het nadrukkelijk betrekken van open source software in de afweging en bij keuze daarvoor de verbeterde componenten via de systemintegrators teruggeven aan de community
3
-
-
componenten beschikbaar stellen als open source software volgens de licentievormen van de ebouwstenen en totale maatwerkapplicatie voor zover dit past in de taakuitoefening van organisaties die het gebruiken. alleen indirecte (via dienstverlener) deelname aan communities het hergebruik van data volgens Marij
b. Interdepartementale ontwikkelingen volger Keuze voor toepassen open source software ligt bij de dienstverlenende partij en zij vallen onder hetzelfde regime als VROM: - aansluiten bij P direct - samenwerking SZW en VWS voor financiële boekhoud applicatie - overgang naar DWR 2.0 c. Bedrijfsvoering volger Dit wordt zichtbaar door: - Het technisch beheer ICT infrastructuur is uitbesteed; het applicatiebeheer is veelal uitbesteed aanpassen van bestaande contracten is niet reëel vanwege kosten - Keuze voor continuïteit van de bedrijfsvoering naast TCO essentieel element van „gelijke geschiktheid‟ - Keuze voor positieve businesscases als open source software voordelen biedt overgang op natuurlijke momenten
Strategische afwegingen In de uitvraag wordt ook nadrukkelijk open source software gevraagd. In het afwegingsproces voor nieuwe software wegen de volgende prioriteiten zwaarder dan dat de software in open source beschikbaar is. Wanneer een open source software alternatief minder bijdraagt aan de volgende doelen dan een closed software alternatief is het niet gelijk geschikt: - Efficiënt beheer - Aansluiting bij rijksbrede ontwikkelingen - Kostenbeheersing De keuze voor open source software wordt ingekaderd door de volgende beleidslijn: - Uitbesteding en inkoop van dienstverlening - Aansluiting interdepartementale initiatieven - Standaard software tenzij en uitfasering maatwerk binnen de bedrijfsvoering Als gekozen wordt voor open source software dan geldt: - Volwassen open source software - De kwaliteit van de programmatuur is goed (stabiel) - Op de markt is support beschikbaar; - Koppelingen met bestaande software moeten mogelijk zijn; - Documentatie is van voldoende kwaliteit; - Relatie dienstverlener – community is bekend en de dienstverlener onderhoudt de relatie; - Softwareomgeving moet veilig zijn; - Geen behoefte om broncode te wijzigen tenzij het software componenten betreft die worden ingezet binnen maatwerk; - Bij het toepassen van software componenten wordt de systemintegrator resultaatverantwoordelijk en participeert zo nodig in de community ( alleen indirecte deelname aan community) - Is de regiefunctie (opdrachtgeverschap) geregeld; - Geen ontwikkeling van expertise op het gebied van open source software voor deelname aan communities (beleid: inkopen van dienstverlening en uitbesteden) Eigen maatwerk als open source software: - Bij toepassing van open source software component is onderdeel opdracht aan systemintegrator teruggave aan community
4
Hoofdstuk 5 Implementatie Architectuur 1. Nagaan op welke punten het open source software beleid consequenties heeft voor de architectuur 2. Open source software een plaats geven het heroverwegingsproces / actualisatie-proces van de architectuur 3. Open source software een plaats geven in het afwegingsproces van vaststelling van standaarden 4. Vervangingskalander opstellen als stuurmiddel voor keuze en afwegingsproces en het realiseren van ambitie
Aanbestedingsbeleid en inkoop 5. het beleid ten aanzien van open source software is vertaald in de aansluitvoorwaarden 6. er wordt expliciet gevraagd aan leveranciers om ook open source software aan te bieden 7. open source software is geen knock-out criterium 8. „gelijke geschiktheid‟ betekent kiezen voor de beste oplossing (TCO, flexibliteit, functionaliteit) 9. expertise aanwezig om closed en open source producten te kunnen wegen
Communicatie en bewustwording 10. in projecten zorgen dat ook kennis van open source software aanwezig bij het opstellen specificaties 11. opname van het onderwerp open source software in de MARAP Kennisontwikkeling - kennisontsluiting 12. er is voldoende kennis van open source software aanwezig bij verwerving 13. een permanent aandachtspunt is dat de „ontwikkelprojecten‟ er steeds voldoende know how is over open source software om dit in het bestek (de functionele specificaties) uit te vragen 14. een (of meerdere medewerkers) het onderwerp open source software in portefeuille geven en dit bekend maken (tevens contactpunt voor programma NOiV) 15. Voor gebruiker is open source software geen issue opleiding geschiedt net als bij closed source software Community 16. VROM neemt geen deel aan een community maar laat dat over aan dienstverlener
Risicomanagement vormgeven Inbedding van open source software 17. Open source software wordt behandeld als gesloten software en is daarmee ingebed in de organisatie 18. Afwegingsproces volgens beleidskader 19. Open source software opnemen in licentiebeheer en configuratiebeheer en contractadministratie 20. Er is voldoende basale kennis van open source software aanwezig zodat deze kan worden worden afgewogen
Vaststelling en sturing De implementatiestrategie is behandeld in ….. en wordt met vastgesteld door ….. en opgenomen in … Rapportage over voortgang van uitvoering van de strategie door …. aan via …..
5
6
Bijlage 2 Conclusies zoals tijdens de strategiemeeting verwoord en impressie a. Conclusies 1. De ambitie geldt voor heel VROM maar de strategie en het beleid om deze ambitie te realiseren kan verschillen voor de verschillende organisatieonderdelen van VROM en is afhankelijk van het primaire proces 2. Gelijke geschiktheid: - in de offerteaanvraag worden ook open source software oplossingen gevraagd maar het niet aanbieden van open source software is geen knock –out criterium - de vragen naar oplossingen worden functioneel uitgevraagd: keuze voor de beste oplossing: tco, continuïteit etc. - gelijke geschiktheid – bij complexe oplossingen – komt bijna niet voor, maar als het voorkomt dan heeft open source software de voorkeur 3. VROM volgt DWR 2.0 4. Maatwerk voldoet aan Marij en Nora en: - waar mogelijk wordt gebruik gemaakt van open source componenten en deze worden wanneer wenselijk beschikbaar gesteld onder open source licentie door de system integrator of leverancier - de relatie met de community verloopt via de leverancier of system integrator 5. Regievoering: het beleid wordt doorgezet naar de uitvoerende partijen 6. In projecten wordt kennis van open source software georganiseerd zodat open source ook daadwerkelijk wordt uitgevraagd; in de staande organisatie is deze aanwezig 7. De architectuur voorziet in een infrastructuur die modulair ontwikkelde toepassingen ondersteunt 8. Communicatie over open source software verloopt via regulieren kanalen 9. Oproep aan Rijk: stel een heldere lijn vast zodat markt kan anticiperen
b. Een korte impressie -
-
-
Is er een programma om de monopolisten aan te pakken? Nee, er is geen specifiek programma. Er is op Nederlands en Europees niveau een mededingingsautoriteit. Daarnaast stimuleert de overheid het gebruik van open source software en zal de markt zich zelf verder ontwikkelen Enthousiasme: o Positieve ontwikkeling van de open source markt; er komen steeds meer producten. o Voor de desktop is veel open source software beschikbaar Bij e-overheid is open source software de de facto standaard. o Open source software zijn vaak slimme en handige producten. o Binnen het geo-domein zijn er veel open source software producten beschikbaar. o Macro-economisch gezien: lokale economie wordt gestimuleerd; de geldstromen zullen anders gaan lopen en meer binnen Europa / Nederland blijven. o Markt van system integrators wordt volwassener. Zij investeren in kennis en werken samen met kleinere bedrijven die al over veel kennis beschikken. Zorgen: o Er is geen geld beschikbaar voor transitiekosten; het oplossen van het legacyprobleem kost geld.
7
o
-
-
-
-
-
-
-
-
Angst voor het hoog uitvallen van de kosten (geleerd van het verleden, Unix systemen).Er zijn nog weinig producten die de gehele diepte ondersteunen van bijvoorbeeld de werkplek o Voor keten samenwerking is er al veel open source beschikbaar maar software die de bedrijfsvoering ondersteunt (ERP) is nog onvoldoende beschikbaar. o Er is behoefte aan gecertificeerde open source software en open source leveranciers. Afnemer moet er van op aan kunnen dat product of dienst goed is. o Zorgen over de eindgebruiker. Die vraagt om duidelijkheid en uniformiteit. Ervaringen tot dusver leiden tot een hogere TCO voor open source software dan voor gesloten source software over het algemeen. 1,5 keer zo duur wordt genoemd. Veel marktwerking is uiteindelijk nodig om dit te veranderen. Commercieel belang kan ook verhinderen dat bij aanbesteding het beste product wordt aangeboden. Kansen voor de inzet van open source producten kunnen worden vergroot bij een keuze voor een kleinschalige en service-gerichte architectuur en gebruikmaking van kleinere componenten (was nadrukkelijke keuze bij geo-oplossing). Ambitie (bij gelijke geschiktheid) geldt voor allen, echter de afhankelijkheid van een goed ingerichte en robuuste ERP toepassing is voor de Rijksgebouwendienst (vastgoedbedrijf) essentieel; een open source variant is niet voorhanden. Casus „ro –online‟: open source software vanwege o Eenvoudig schaalbaar, vanwege ontbreken licentiekosten o Stapelbaarheid en open koppelvlakken (geen leverancierspecifieke standaarden) o Systemintegrator nam verantwoordelijkheid o Lagere TCO dan closed source concurrent o Slechts 1 leverancier, maar wel veel sturingsmogelijkheden door modulaire architectuur o Volwassener dan closed source concurrent Geen bereidheid om concessies te doen aan de gevraagde functionaliteit en prijs ten gunste van open source software. Wel nadrukkelijk 'open source' in de afweging betrekken en in de weging een plek geven Leveranciers moeten buiten de kaders gaan denken en samenwerking tussen systemintegrators en pakketleveranciers kritisch bezien. “Doe het eens anders.” De vergelijking met duurzaam inkopen wordt getrokken Bij inkopen dienstverlening wordt er niet specifiek gevraagd om open source software. Er zal slechts worden aangegeven dat hier prijs op wordt gesteld en er wordt verwezen naar de motie Vendrik. De overheid geeft een stimulans maar de markt moet het verder ontwikkelen Binnen projectmanagement moet er enige kennis van open source software zijn (ook deze kennis is in te huren of te kopen) Gelijke geschiktheid komt bijna niet voor, maar als het voorkomt dan heeft open source software de voorkeur Politiek moet nadenken en een heldere boodschappen geven. Wil je echt iets bereiken dan moet je verplichten.
Bijlage 3. Toelichting op open source software Wat is Open Source Software? In wezen is het software net als andere software. Op het meest basale niveau betekent de term open source software simpelweg dat de broncode open en beschikbaar is. De broncode is het programma waarin de software origineel is geschreven. Software wordt als 'open' beschouwd als de broncode gelezen, aangepast en verspreid mag worden. Beschikbaarheid betekent dat iedereen de code gratis of tegen een nominaal bedrag kan verkrijgen.
8
De definitie van het Open Source Initiative (OSI), de zogenaamde Open Source Definition (OSD), bestaat uit tien regels waar software aan moet voldoen voordat het Open Source Software (OSS) mag worden genoemd. De belangrijkste elementen uit deze definitie zijn het recht om de software zonder beperkingen te mogen distribueren en om de bron code te mogen inzien en naar eigen inzicht te mogen aanpassen. Zie: http://www.opensource.org/docs/osd Wat zijn de verschillen met closed source software? Ontwikkeling:community en bedrijven Open Source Software onderscheidt zich van traditionele, gesloten software onder andere door de wijze waarop de software wordt ontwikkeld. Een OSS project bestaat uit een community (gemeenschap) van vrijwillige en gemotiveerde leden. Bedrijven kiezen er ook soms voor om medewerkers te laten participeren in communities. Dit is te zien als een investering. Redenen om hierin te stappen lopen uiteen van: motiverend voor medewerkers, kennis ontwikkeling, invloed uitoefenen op het product, duurzaam ondernemen door kennis en expertise ter beschikking te stellen. Dagelijkse praktijk is dat bedrijven als IBM, SUN, Novell participeren in software projecten als Linux, Open office et cetera. Deze manier van ontwikkelen heeft volgens sommigen het voordeel dat releases en bugfixes sneller worden uitgebracht en daarmee de kwaliteit van de software beter is dan die van proprietary software. Daarnaast kunnen leveranciers zelf ook deelnemen aan deze communities en daardoor invloed hebben op de functionaliteit van de software. Beheer: Community versus Commerciële partij Bedrijven die hun geld verdienen met het installeren van - de vaak gratis - Open Source software producten kunnen ook zeer succesvol zijn. Dit alles heeft te maken met de aanvullende diensten. Diensten als support, maatwerk en onderhoud zijn zeer goed winstgevend te krijgen. Dit verschilt dus niet van gesloten software. Indien er een dienstverlener voor de betreffende open source is kan deze dus voor een deel of geheel de risico's ten aanzien van beheer en support overnemen. Indien dit niet mogelijk is, bijvoorbeeld door het ontbreken van geschikte dienstverlener (wat in Nederland zeker het geval kan zijn, terwijl het toch om een 'volwassen' product gaat) dient men terug te vallen op de community. Dit vergt ander risicomanagement. Licentiemodel: Er zijn enorm veel typen licenties in omloop. Aanbieders van gesloten software hanteren vaak hun eigen licenties. Open-source software projecten gebruiken vaak bestaande licenties, zoals de GNU General Public License (GPL), maar schrijven soms ook eigen licenties voor specifieke projecten. Hierin worden dan bepalingen opgenomen wat er met de broncode gedaan mag worden (verspreiden, inzien, aanpassen etc.). Voor de exacte bepalingen van zowel gesloten software licenties als open source licenties dient goed in de documentatie gekeken worden. De traditionele, gesloten standaard software (pakketten) wordt over het algemeen ontwikkeld voor rekening en risico van de ondernemer en de kosten van ontwikkeling, doorontwikkeling en foutherstel worden terugverdiend via het verkopen van het gebruiksrecht (licentiekosten) en supportcontracten. De continuïteit van het product hangt meestal af van het succes. Het eigendom van software die een leverancier (in opdracht van de overheid) ontwikkelt wordt in overleg bepaald. De rijksoverheid is over het algemeen eigenaar. Andere overheden kiezen ook wel voor modellen dat de leverancier het product al dan niet in aangepaste vorm vermarkt. Wat is de relatie met open standaarden? Open Source Software en open standaarden worden vaak in één adem genoemd. Toch zijn dit twee zeer verschillende onderwerpen. Waar open standaarden betrekking hebben op het maken van gezamenlijke
9
afspraken (omtrent bijvoorbeeld gegevensuitwisseling), is Open Source Software een juridische constructie die leidt tot alternatieve businessmodellen voor de ontwikkeling van software. Toch is er wel enige overlap: in veel gevallen maakt open source software louter gebruik van open standaarden. Wat kan het voor mij betekenen? Bij overheidsorganisaties komt deze vraag vooral voort uit wat het kabinetsbeleid ten aanzien van open source software voorschrijft. Bij de keuze voor nieuwe software gaat het om het maken van een bewuste afweging tussen open source en gesloten source. Immers het kabinetsbeleid schrijft voor: bij gelijke geschiktheid heeft open source de voorkeur.. Dit is een forse inspanningsverplichting. Op allerlei niveaus binnen de (semi-)publieke sector bestaan contracten met leveranciers die niet of nauwelijks opengebroken kunnen worden en ook wijzigingen in het applicatielandschap laten zich niet altijd zo eenvoudig aanbrengen. Daarom is het goed de mogelijkheden voor open source binnen de architectuur – dus in samenhang - te verkennen want dat gaat vooraf aan de aanbestedingen. Het Kabinet wil dat bij aanbestedingen en inkooptrajecten van software voor nieuw- of verbouw en contractverlenging de aanbieders van open source software daadwerkelijk in de praktijk dezelfde kansen krijgen. Bij gelijke geschiktheid heeft open source software de voorkeur. Bij de feitelijke aanbesteding wordt het effect van het beleid zichtbaar maar de keuze wordt eerder in het proces gemaakt. Wat zijn aandachtsgebieden voor het vormgeven van gelijke geschiktheid? Volwassenheid Afhankelijk van de inzet van de betreffende functionaliteit is de volwassenheid van het product belangrijk. Kijk hierbij naar de activiteit van een community (mailinglijsten, releases, berichten op forums etc), hoe lang het project al bezig is, hoe professioneel is het beheer. Maar kijk ook het aantal dienstverleners die er actief mee bezig zijn, waar is het allemaal ingezet etc. De grote dienstverleners (stand van zaken begin 2009) beschikken over assesment methoden op de kwaliteit – in brede zin - van de open source software. Continuïteit Binnen de open source software wereld lopen rijpe en groene producten door elkaar heen. Dit is in de closed source software wereld natuurlijk niet anders, alleen valt het hier minder op. Een veel gehoord risico van open source software is de continuïteit: als er geen commercieel bedrijf achter zit, wat is dan de levensvatbaarheid van zo'n product? Intussen komen er steeds meer dienstverleners die support leveren op open source software. De community – waarin gebruikers op de een of andere manier - participeren bepalen de continuïteit en doorontwikkeling. De leveranciers bepalen de continuïteit van de commerciële software al dan niet onder invloed van een gebruikers vereniging. Support Er is nog niet voor alle software professioneel support te verkrijgen. Door de beweging van onder andere HP, SUN en IBM begint hier echter verbetering in te komen. Sinds een aantal jaar kunnen medewerkers gecertificeerd worden voor diverse open source producten. Deze certificering maakt het eenvoudiger een vraag naar een specialist in de markt te zetten of de eigen medewerker op te leiden en de inzetbaarheid te verbeteren. Aansprakelijkheid In OSS-licenties wordt aansprakelijkheid vergaand uitgesloten en worden geen garanties gegeven voor de werking van de software. Daardoor is het meestal niet mogelijk om de gemeenschap van programmeurs
10
(community) van de open source software hierop in rechte aan te spreken. Open source licenties staan echter wel toe dat aanvullend afspraken worden gemaakt over garantie en aansprakelijkheid. Een overheidsorganisatie die zich wil indekken tegen schade door softwarefouten, zal daarom goede afspraken moeten maken met de dienstverlener die de software implementeert danwel beheert. Een overheidsorganisatie kan bijvoorbeeld van zijn dienstverlener verlangen dat hij bepaalde garanties geeft met betrekking tot de maximale uitvalsduur van het informatiesysteem. Dit is niet anders dan de afspraken die u hieromtrent zou maken met een levencier die gesloten broncode software bij u installeert. Veiligheid Ten aanzien van de veiligheid van software wordt door critici van open source software gezegd dat kwaadwillenden de mogelijkheid hebben om de broncode te bekijken en misbruik te maken van fouten in de code. Hiertegen zijn echter wel een aantal argumenten te noemen: Snelle detectie en correctie van fouten voor veel gebruikte en ondersteunde OSS Men kan zelf meteen de 'fout' herstellen, niet afhankelijk van een derde partij Iedereen kan veiligheid beoordelen en suggesties ter verbetering aandragen Openbaar maken van een systeem maakt dat het systeem echt veilig moet zijn, programmeurs werken beter als systeem 'open en transparant' is Gereduceerd risico van 'achterdeurtjes' Open source software wordt veel ingezet door organisaties die beveiliging als kerntaak hebben. Bijlage 4 Redenen om te kiezen voor open source software – zoals gehoord -. Goed opdrachtgeverschap -> kiezen op basis van overzicht en onafhankelijkheid Niet te veel betalen voor software -> dus maar een keer Kansen voor open standaarden omdat open source software veelal gebaseerd is op open standaarden Inzet van kleine componenten biedt kansen voor een open en flexibele architectuur Transparantie is veiligheid Stimulerend om mee te werken -> bevordert creativiteit (vooral voor organisaties die zelf software ontwikkelen) Bevordert innovatie Principiële redenen: - Werken als community - Vrije aanpasbaarheid - eis van transparantie: alleen nog dingen waarvan je kunt weten wat erin in zit, hoe het werkt
11
