Beleid Open Standaarden en Open Source Software Rijn Oost Waterschappen

Transcriptie

1 Beleid Open Standaarden en Open Source Software Rijn Oost Waterschappen Versie 0.5 I-coördinatoren Rijn Oost 12 oktober 2009

2 VERSIEBEHEER Versie Datum Omschrijving mei 2009 Eerste concept door Paul van der Weerd, Vincent Hovinga en Erik Sloothaak ter bespreking in het ICRO overleg van 4 juni juni 2009 Opmerkingen ICRO overleg deelnemers verwerkt juni 2009 Hoofdstuktitel en inhoudsopgave aangepast sep 2009 Aanschafkosten open source software in tabel aangepast okt 2009 Formulering van de meerwaarde van open standaarden aangepast (laatste paragraaf van hoofdstuk 3) Beleid OS en OSS Rijn Oost v0 5.doc 1

3 INHOUDSOPGAVE 1. Inleiding Definities Wat zijn Open Standaarden? Wat is Open Source Software? Wat is freeware? Wat is shareware? Publieke software vs. commerciële software Principes bij de keuze van software Eindbeeld (ambitie) Strategie bij de aanschaf van nieuwe software Business case aspecten Beleid OS en OSS Rijn Oost v0 5.doc 2

4 1. INLEIDING Aanleiding De afgelopen jaren is de werkwijze van waterschappen net als van andere overheden ingrijpend veranderd. Er wordt steeds meer van overheidsorganisaties verwacht dat ze samenwerken in ketens, informatie delen en uitwisselen. Aanvankelijk vooral binnen de organisatie, maar in toenemende mate ook tussen verschillende organisaties en met burger en bedrijf. Aldus worden waterschappen in toenemende mate netwerkorganisaties. Dit is alleen mogelijk als interoperabiliteit 1 tussen de onderdelen van het netwerk en de ketens is geborgd. Het hanteren van standaarden is noodzakelijk om gegevens te kunnen uitwisselen. De informatiesystemen van de Waterschappen zijn in de afgelopen decennia organisch gegroeid. Daarbij bestond zeker aanvankelijk- weinig aandacht voor de uitwisselbaarheid van bestanden en zaken als open of gesloten software. Enerzijds werd er weinig uitgewisseld en anderzijds was er ook weinig te kiezen. Dit is inmiddels anders. Daarom is het noodzakelijk om nu beleid te formuleren om bewuste keuzes te kunnen maken ten aanzien van standaarden en software. Dit bewustzijn bestaat niet alleen onder informatiemanagers binnen de overheid. Ook bestuurlijk staan deze onderwerpen op de agenda: De Europese Commissie stimuleert interoperabiliteit door middel van het programma IDABC. 2 In Nederland zijn Open Standaarden en Open Source Software sinds de motie-vendrik is aangenomen (november 2002) een politiek thema. De promotie van Open Standaarden en Open Source Software is staand kabinetsbeleid. Hiertoe is een actieplan geschreven en een programmabureau ingericht onder de titel Nederland Open in Verbinding (NOiV). 3 Dit kabinetsstreven is door de ondertekening van het Nationaal Uitvoeringsprogramma betere dienstverlening (NUP) ook geadopteerd door gemeenten, provincies en waterschappen. Scope van voorliggend document Dit document geeft de gezamenlijke visie weer die we als Rijn Oost Waterschappen hebben op Open Standaarden en Open Source Software. Het is géén inhoudelijk pleidooi voor of tegen Open Standaarden of Open Source Software, maar biedt een afwegingskader om te komen tot doordachte keuzes ten aanzien van deze zaken. De aanschaf van Open Source Software is niet wezenlijk anders dan die van gesloten software, mits alle aspecten uit de business case worden meegenomen. Daarom wordt geen specifieke aandacht besteed aan inkoop en aanbesteding. Bij Waterschappen is het niet gebruikelijk zelf software te (laten) ontwikkelen. Daarom wordt in dit document geen stelling ingenomen ten aanzien van de verspreiding van zelf ontwikkelde software. 1 De door NORA gehanteerde definitie van interoperabiliteit is: The ability of two or more systems or elements to exchange information and to use the information that has been exchanged. Deze definitie is afkomstig van: The Authoritative Dictionary of IEEE Standards Terms (IEEE 100) IDABC=Interoperable Delivery of European egovernment Services to public Administrations, Businesses and Citizens Beleid OS en OSS Rijn Oost v0 5.doc 3

5 2. DEFINITIES Voor een goed begrip van dit document worden in dit hoofdstuk een tweetal belangrijke begrippen gedefinieerd: open standaarden en Open Source software. Voor een compleet beeld worden ook de begrippen freeware en shareware uitgelegd. 2.1 WAT ZIJN OPEN STANDAARDEN? 4 Het gaat om standaarden ten behoeve van interoperabiliteit van informatiesystemen (ofwel het kunnen uitwisselen van gegevens tussen computerprogramma s). Standaarden kunnen open zijn of gesloten. Door open standaarden te gebruiken in plaats van standaarden die leveranciergebonden zijn (door intellectueel eigendomsrecht) kan de gebruiker informatie vastleggen in een formaat waarvan een algemeen toegankelijke definitie bestaat. Hoewel Open Source software vaak (ook) gebruik maakt van open standaarden is dat niet noodzakelijk. Gesloten source software kan met open standaarden omgaan en omgekeerd (ondanks het ontbreken van een beschikbare definitie). Onder een open standaard verstaan we een standaard die voldoet aan de volgende eisen: 1. De standaard is goedgekeurd en zal worden gehandhaafd door een not-for-profit organisatie, en de lopende ontwikkeling gebeurt op basis van een open besluitvormingsprocedure die toegankelijk is voor alle belanghebbende partijen (consensus of meerderheidsbeschikking enz.); 2. De standaard is gepubliceerd en over het specificatie document van de standaard kan vrijelijk worden beschikt of het is te verkrijgen tegen een nominale bijdrage. Het moet voor een ieder mogelijk zijn om het te kopiëren, beschikbaar te stellen en te gebruiken om niet of tegen een nominale prijs; 3. Het intellectuele eigendom - m.b.t. mogelijk aanwezige patenten - van (delen van) de standaard is onherroepelijk ter beschikking gesteld op een royalty-free basis; 4. Er zijn geen beperkingen omtrent het hergebruik van de standaard; Om standaardisatie binnen de overheid te bewerkstelligen is in 2006 het College en het Forum Standaardisatie ingesteld. De Nederlandse Overheids Referentie Architectuur NORA, die ook door Forum en College wordt uitgedragen, schrijft bij voorkeur open standaarden voor. Het gebruik van open standaarden wordt inmiddels ook door de Europese Commissie als beleid genomen: For all parties involved, the exchange of documents and data between authorities, businesses and citizens must be possible without technical barriers. The public administration must not exclude anyone from participating in an electronic procedure owing to the use of a specific product. The Member States are agreed that in the future electronic documents should be exchanged fully on the basis of open document exchange formats (Berlijn; 2007). 2.2 WAT IS OPEN SOURCE SOFTWARE? 5 Open Source software is software met twee kenmerken: De broncode van de software is vrij beschikbaar. In het licentiemodel is het intellectueel eigendom en het (her)gebruik van de software en bijbehorende broncode dusdanig geregeld dat de licentienemer de broncode mag inzien, gebruiken, verbeteren, aanvullen en distribueren. Een Open Source licentie dwingt af dat de broncode van het product, en soms ook de aanpassingen daarop, vrij beschikbaar moet zijn. Om helder te maken wanneer software Open Source software genoemd mag worden, zijn door de Open Source Initiative voorwaarden opgesteld waaraan een 4 Bron: 5 Bron: Beleid OS en OSS Rijn Oost v0 5.doc 4

6 licentie moet voldoen, zodat de software die onder die licentie vrijgegeven wordt, Open Source genoemd mag worden. Deze vrijheid om de software aan te passen heeft ertoe geleid dat belanghebbenden gezamenlijk werken om de software te verbeteren of uit te breiden, zonder dat eigendomskwesties deze samenwerking in de weg zitten. Deze nieuwe vorm van samenwerking, waarbij personen uit verschillende organisatie, landen of op persoonlijke titel gezamenlijk de software verder ontwikkelen (Open Source communities), wordt de Open Source ontwikkelmethode genoemd. Een belangrijke reden om een Open Source oplossing te gebruiken is dat men voordelen ziet in de snelle aanpassingen die vaak het gevolg zijn van deze methode, dus ook als men zelf niet als ontwikkelaar bijdraagt. Bij de meeste Open Source oplossingen hoeft de gewone gebruiker dus niet te (kunnen) programmeren. 2.3 WAT IS FREEWARE? 6 Freeware is een gangbare benaming voor software waarvan de auteur een licentie heeft verleend tot gebruik en verdere verspreiding in ongewijzigde vorm, zonder daarvoor vergoeding te vragen. In tegenstelling tot Open Source software wordt freeware meestal volledig beschermd door auteursrechten. Zo wordt de broncode van freeware over het algemeen niet beschikbaar gesteld en geeft de auteur de gebruiker niet het recht de programmatuur aan te passen of aangepaste versies verder te verspreiden. Het Engelse woord free betekent in de context van freeware dus gratis en niet vrij. Freeware is in de meeste gevallen dus geen Open Source software. 2.4 WAT IS SHAREWARE? 7 Shareware is een vorm van software die zonder of met weinig restricties verspreid mag worden, maar waarvoor bij herhaald gebruik wel een vastgelegd bedrag betaald moet worden. In de licentie van shareware software is beschreven: wie er rechten op distributie van de software hebben. Dit kan iedereen zijn, maar ook een selecte groep. dat gebruikers de software kunnen proberen in een proefperiode, voordat er tot betaling moet worden overgegaan. Door software als shareware te verspreiden, verlaagt de producent vaak zijn kosten, omdat er bijvoorbeeld geen verpakking nodig is, en verspreiding kosteloos wordt afgehandeld door derden. De grens tussen shareware en traditionele commerciële software is in de jaren 1990 vager geworden, omdat aanbieders van die laatste categorie steeds vaker probeerversies van hun programma s gingen verspreiden via traditionele distributiekanalen voor shareware als downloadsites en bij computerbladen horende cd-roms en dvd-roms. 2.5 PUBLIEKE SOFTWARE VS. COMMERCIËLE SOFTWARE Naast de hiervoor genoemde categorieën software is de meeste software nog van commerciële aard. In de volgende tabel worden de verschillende categorieën software op een aantal aspecten met elkaar vergeleken: 6 bron: bewerkt 7 bron: bewerkt Beleid OS en OSS Rijn Oost v0 5.doc 5

7 commerciële software freeware shareware open source software licentievorm kopen gebruiksrecht bruikleencontract kopen gebruiksrecht bruikleencontract ondersteuning meestal verplicht geen alleen updates naar keuze aanschafkosten hoog gratis laag gratis of laag beschikbaarheid sourcecode gebaseerd op open standaarden geen geen geen geheel of gedeeltelijk productafhankelijk wisselend zelden meestal Iedere softwarevorm heeft een unieke aspectinvulling. Om een keuze te maken tussen de verschillende softwarevormen, is het noodzakelijk om een dusdanige reeks aspecten mee te nemen dat een goede afweging mogelijk is. Open Source software is dus niet fundamenteel anders: het blijft gewoon software! Het aspect gebaseerd op open standaarden heeft een bijzondere rol, omdat het bepalend is voor de implementeerbaarheid van nieuwe software (met die eigenschap) in de toekomst. Het aspect verruimt als het ware de toekomstige keuzemogelijkheden. Dit is een belangrijke reden voor veel organisaties om het aspect gebaseerd op open standaarden als noodzakelijke voorwaarde te hanteren Beleid OS en OSS Rijn Oost v0 5.doc 6

8 3. PRINCIPES BIJ DE KEUZE VAN SOFTWARE De implementatie van nieuwe software betekent meestal een uitbreiding of aanpassing van een bestaande ICT-infrastructuur, waarin al de nodige software operationeel is. Er gelden bij aanschaf van nieuwe software daarom twee eisen: 1. de nieuwe software dient goed samen te werken met de bestaande software (interoperabiliteit met bestaande software) 2. de nieuwe software moet het goed samenwerken met toekomstige software niet onmogelijk maken (interoperabiliteit met toekomstige software) Om te voldoen aan deze eisen stellen we het hanteren van de volgende principes voor: Bevrijding Een keuze voor een specifiek softwarepakket moet zo weinig mogelijk beperkend werken op andere softwarepakketten waaruit later gekozen gaat worden. M.a.w. een keuze nu moet zo weinig mogelijk impact hebben op een keuze later. Ontvlechting Het correct werken van software (die een bepaalde functionaliteit verzorgt) moet zo min mogelijk afhangen van het (correct) werken van andere software. M.a.w. het aantal verbindingen tussen verschillende softwarepakketten moet beperkt blijven tot de hoogst noodzakelijke. Ook is het van belang om te leren van vergelijkbare situaties. We willen het wiel niet opnieuw uitvinden. Als er elders goede ervaringen met bepaalde software, dan willen we daarvan profiteren. Dit vraagt om het principe: Aansluiting Bij de keuze van een softwarepakket dienen we maximaal gebruik te maken van opgedane ervaringen bij vergelijkbare organisaties (bijv. waterschappen, gemeenten). M.a.w. we kiezen zoveel mogelijk voor een beproefd, courant softwarepakket. Verder geldt dat bijna alle softwarepakketten veel meer functionaliteiten bevatten dan de noodzakelijke. Omdat iedere functionaliteit een bepaalde inspanning kost, zowel voor het implementeren als voor het ondersteunen, is het gewenst om alleen het noodzakelijke te gebruiken. Dit is verwoord in het principe: Begrenzing Bij het implementeren van software moeten we duidelijk maken wat de bedoeling is van het gebruik, en welke werkwijze dat betekent voor de gebruiker. M.a.w. het moet duidelijk zijn wat de reikwijdte is van het gebruik, en welke functionaliteiten kunnen rekenen op support. Samengevat hanteren we bij de implementatie van nieuwe software dus vier principes: Bevrijding (van specifieke merken) Ontvlechting (van functionaliteiten) Aansluiting (op andere organisaties) Begrenzing (van het bedoelde gebruik) Het eerder genoemde aspect gebaseerd op open standaarden valt onder het principe bevrijding, omdat het de keuzevrijheid bij de aanschaf van nieuwe software vergroot. De keuze voor Open Source software levert alleen een bijdrage daarin indien deze op open standaarden is gebaseerd. Verder geldt: in situaties waarin interoperabiliteit geen vereiste is, zal een keuze voor open standaarden pas in de toekomst meerwaarde opleveren. Het kan wèl direct bijdragen aan het bedrijfsbreed op een vastgestelde wijze werken, waardoor het delen van ervaringen tussen medewerkers makkelijker is Beleid OS en OSS Rijn Oost v0 5.doc 7

9 4. EINDBEELD (AMBITIE) Uitgangspunt bij de bepaling van de ambitie is dat keuzes bij ICT initiatieven het gevolg zijn van uitgebreide en zorgvuldige onderbouwing (de businesscase, zie hoofdstuk 6). In de businesscase zal onder andere aandacht besteed moeten worden aan nut en noodzaak en kosten en opbrengsten (zowel financieel als in bijdragen aan doelstellingen). De ambities op het gebied van open standaarden en Open Source zullen onderdeel uitmaken van de business case. Hierbij blijft het van belang om te realiseren dat de ambities op het gebied van open standaarden en Open Source betrekking hebben op het middel en geen op zichzelf staand doel zijn. De totale businesscase bepaalt de keuze. Het voorgaande leidt er toe dat de ambities op het gebied van open standaarden en Open Source software niet als absolute waarden worden gedefinieerd, maar in de vorm van streefbeelden: De ambitie met betrekking tot open standaarden is als volgt: Daar waar mogelijk voldoet software aan open standaarden. De overtuiging is dat daar waar interoperabiliteit een belangrijk aspect voor een te kiezen oplossing is, het aspect open standaarden een bijbehorend gewicht in de bepaling van de business case gaat krijgen. Gevolg zal zijn dat alleen op gebieden waar sprake is van beperkt interoperabiliteitseisen er mogelijk afwijkingen zijn. Een kanttekening die wordt gemaakt is dat gebruik van algemeen geaccepteerde gesloten standaarden niet wordt uitgesloten. Voorwaarde is dan wel dat de gesloten standaard breed geaccepteerd en toegepast wordt (bijvoorbeeld in het verleden het niet-gestandaardiseerde pdf bestandsformaat wat door de grote acceptatie inmiddels tot open standaard (pdf/a) is verheven). Met betrekking tot Open Source software is de ambitie als volgt: Er ontstaat een landschap van software producten waarin ook Open Source software vertegenwoordigd is. Voor alle gebruikte software is een onderbouwde keuze gemaakt. Deze situatie wordt gerealiseerd door Open Source software nadrukkelijk in de afweging mee te nemen. Het uitgangspunt dat bij gelijke geschiktheid gekozen wordt voor Open Source software, in combinatie met een keuze op basis van een businesscase, zorgt voor de realisatie van deze ambitie. Over de snelheid waarmee de ambitie te realiseren is valt nog niet veel te zeggen. Hierbij zijn factoren als het moment van vervanging van bestaande software, maar ook bijvoorbeeld de roadmap van een leverancier van belang. Belangrijk om te realiseren is dat een groot deel van de door waterschappen gebruikte software tot stand komt via samenwerking middels het Waterschapshuis. Het is daarom van belang dat ook het Waterschapshuis de gehanteerde principes deelt en hanteert Beleid OS en OSS Rijn Oost v0 5.doc 8

10 5. STRATEGIE BIJ DE AANSCHAF VAN NIEUWE SOFTWARE Het consequent hanteren van de in hoofdstuk 3 genoemde principes bevrijding en ontvlechting zorgt voor een optimale flexibiliteit van het softwarelandschap. Het betekent een gaandeweg toe groeien naar een softwarelandschap waarin het vervangen of toevoegen van functionaliteiten weinig (of geen) impact heeft op de overige functionaliteiten. Voordat we de aanschaf van Open Source software gaan overwegen, dienen we daarom eerst de flexibiliteit van het bestaande softwarelandschap te onderzoeken en zonodig te verbeteren. Het feit dat Open Source software en ook alternatieve commerciële software vaak geen serieus alternatief zijn voor reeds aanwezige software is namelijk vaak een gevolg van het niet toepassen van de principes bevrijding en ontvlechting. Het hanteren van alleen de beschreven principes bij de aanschaf van nieuwe software is uiteraard niet voldoende. Uitgangspunt blijft dat de nieuwe software minimaal moet voldoen aan de functionele behoefte. Verder kan het overwegen van Open Source software het beste starten op een natuurlijk moment : een tijdstip waarop het vervangen of uitbreiden van een bestaand commercieel softwarepakket (nieuwe release) een grote impact heeft op de bestaande situatie. Naast de consequenties voor andere softwarepakketten, is er op zo n moment meestal ook behoefte aan een uitgebreide training van medewerkers. Samengevat bestaat de strategie voor het implementeren van Open Source software uit de volgende stappen: Onderzoek de flexibiliteit (vervanging of uitbreiding zonder impact) van het bestaande softwarelandschap. Verbeter zonodig de flexibiliteit door toepassing van de principes bevrijding en ontvlechting. Neem een Open Source alternatief mee in elke business case. Als de situatie het toelaat, maak dan voor de overweging van Open Source software gebruik van een natuurlijk moment Beleid OS en OSS Rijn Oost v0 5.doc 9

11 6. BUSINESS CASE ASPECTEN In deze visie wordt niet het volledige proces van het schrijven van een business case behandeld. Wel worden hierna een aantal aspecten genoemd die vanuit het oogpunt van open standaarden en Open Source aandacht moeten krijgen in de business case: Aandachtspunt 1: Aandacht voor Open Source In de business case dient beschreven te worden dat er expliciet is gekeken naar Open Source software. Indien in de uiteindelijke businesscase geen Open Source software wordt afgewogen dient hiervoor een reden genomen te worden. Aandachtspunt 2: Interoperabiliteit Bepaald dient te worden in hoeverre de uitwisseling van gegevens met andere software en/of andere organisaties van belang is voor aan te schaffen software. Indien dit belang groot is dient de oplossing te voldoen aan open standaarden. Aandachtspunt 3: Ondersteuning In de businesscase dient te worden aangegeven hoe in het geval van Open Source software de ondersteuning geregeld gaat worden (staat er een grote organisatie achter of moet dit zelf georganiseerd worden?). De kosten voor deze ondersteuning dienen te worden meegenomen. Ook moet bekeken worden welke kennis in de eigen organisatie nodig is. Aandachtspunt 4: Volwassenheid Open Source software is in allerlei stadia van volwassenheid beschikbaar. Uitgezocht dient te worden in welk volwassenheidsstadium het beoogde Open Source zich bevindt, en welke mogelijke risico s dit met zich meebrengt. Aandachtspunt 5: Ontwikkeling Vindt er op de gekozen Open Source software ontwikkeling plaats? Is er sprake van een actieve community? Beleid OS en OSS Rijn Oost v0 5.doc 10