Overheid en Open Source, een open deur?

Van de week was het weer zover, Nederland buitelde over elkaar heen met kritiek op ICT van de overheid. Dit alles omdat een groot deel van de overheid, zowel lokaal als rijksbreed, nog niet is overgestapt van het operating systeem Windows XP naar een meer up to date variant, terwijl Microsoft al tijden geleden heeft aangekondigd (en overigens al eens heeft uitgesteld) dat de ondersteuning voor deze versie wegvalt. Lastig inderdaad, het levert een flink veiligheidsrisico op dat via (kostbare) omwegen nu weer moet worden opgelost. Van links en rechts hoorde ik de roep om open source en dat het belachelijk is dat de overheid kiest voor commerciële leveranciers. Dit lijkt een logische gedachte, maar is erg naïef. Ik leg je uit waarom.

Calimero
Ik hoor het vaak, de over het algemeen zure opmerkingen over de combinatie overheid en ICT. Het is niet goed of het deugt niet, daar komt het ongeveer op neer. Niet zelden met enige arrogantie vanuit de commerciële hoek. Vaak terecht overigens, het is niet de sector met de meest vooruitstrevende instelling op dat gebied en ja, fouten worden zeker gemaakt. Ik vind het doodzonde als ik lees over duizenden euro’s voor ICT systemen die misschien best op een eenvoudiger manier ingericht kunnen worden. De oplossing ‘kies dan voor open source, dat kost niets qua licenties’ ligt voor de hand.

Juist daar ligt de denkfout. Open source is heel leuk, als je kunt rekenen op een actieve community, die jouw behoefte bedient. Daar zit ‘m de crux. Voor een Office-achtige omgeving op je persoonlijke pc waar miljoenen anderen ook behoefte aan hebben is dat geen probleem, maar de overheid is beperkt qua grootte en heeft vaak een zeer specifieke behoefte. Eentje die je aan de voorkant niet direct ziet, een website is een website toch? En een logitiek systeem is een logistiek systeem. Zou je zeggen, ware het niet dat de activiteiten van de overheid vragen om systemen en koppelingen die je in een andere sector niet snel zult vinden. Natuurlijk kan (en moet) daar aan gewerkt worden, het is alleen nog geen realiteit.

Vijf overwegingen
Je ‘community’ met dezelfde behoefte is voor overheidsorganisaties bij definitie klein. Dat betekent een aantal dingen:

1) Een open source product levert een basis, maar veel benodigde functionaliteit (maatwerk voor overheidsorganisaties) is daarin nog niet beschikbaar en zal zelfstandig gebouwd en toegevoegd moeten worden. In het geval je wel door kunt borduren op bestaande software, houd er dan rekening mee dat je de onderdelen die je overneemt zult moeten aftesten. Je wilt immers weten wat voor code je naar binnen haalt. Daar heb je de juiste kennis en het juiste beleid voor nodig.

2) Deze nieuwe functionaliteit wordt nog niet beheerd, ook dit zal je als overheidsorganisatie dan zelf moeten inregelen.

3) Je voegt nieuwe bruikbare functionaliteit toe voor de overige gebruikers van het open source product, maar de afnemers zijn zo beperkt dat dit weinig voordeel op levert.

4) En dat betekent dat ook nieuwe versies en verbeteringen door de overheid zelf ontwikkeld moeten worden. Het is meestal niet interessant genoeg voor de overige gebruikers.

5) Een open source community draait vaak om een aantal key spelers: belangrijke gebruikers of ontwikkelaars. Als deze wegvallen, is het risico volledig voor de overheid, waar dit in het geval van een commercieel product een verantwoordelijkheid van de leverancier is. De afnemers zouden daar geen last van mogen hebben.

Investeren of fixed price
Dit alles gecombineerd levert een flink kostenplaatje op. De overheid hoeft in eerste instantie geen gebruiksrecht te betalen, dat is natuurlijk een geweldig voordeel. Het voordeel wordt alleen in de schaduw gezet door alle additionele kosten waar je vanaf de afname tot aan het eind van de inzet van het product mee geconfronteerd wordt. Inhuur van ontwerpers, bouwers en architecten plus het opzetten en draaiend houden van een beheerorganisatie. Een commercieel product, vangt dit over het algemeen in een fixed price, eventueel aangevuld met implementatiekosten. Bovendien maak je door het aangaan van een contract aanspraak op de geldende regelgeving, garantie, regulier onderhoud en updates enzovoort. Daarnaast, niet onbelangrijk, mocht er bijvoorbeeld security-wise iets mis zijn met het product dan kan je de leverancier hier op aanspreken.

In dat geval ben je als overheid een klant, de afnemer, waar je bij een open source product vaak initiator, eigenaar en verantwoordelijke bent. Wil je als organisatie die taken en kosten op je nemen?

Richt je op flexibiliteit
Mijn advies is daarom om altijd een afweging te maken bij het inzetten van een (nieuw) product. Ja, de overheid moet open source elke keer als optie meenemen en de mogelijkheden onderzoeken. Maar: doe dit op basis van een kosten-baten analyse met de punten zoals ik die hierboven beschreef in het achterhoofd. Is de total cost of ownership over de periode waarin je het product inzet, zo’n vijf jaar, lager als je kiest voor open source?

By default
Een principieel uitgangspunt kan hier een rol in spelen, je kunt als organisatie kiezen voor een ‘open source by default’ instelling, ofwel altijd open source, tenzij. Houd in dat geval rekening met landurige extra kosten, is daar de ruimte voor en is dat het waard? Het antwoord kan in veel gevallen -ja- zijn, maar zorg er voor dat het geen must wordt. Kies voor de best passende oplossing, zowel qua product, als qua financiën. Wees eerlijk. Zo houdt je de organisatie en de oplossingen die je kiest flexibel.

Advertisements

15 thoughts on “Overheid en Open Source, een open deur?

  1. Pingback: Vier Snelle Links – 12 april 2013 | Annemarie van Campen

  2. Hallo Annemarie,
    We zijn het inderdaad eens dat de overheid een zakelijke afweging zou moeten maken over de total cost of ownership bij de aanschaf van software. Ik vind dan ook niet dat open source een must is. Maar je blog gaat verder dan de stelling dat er een objectieve afweging moet worden gemaakt. Je verhaal is een aaneenschakeling van expliciete en impliciete waarschuwingen voor allerlei risico’s en nadelen die in jouw ogen aan open source kleven. Deze zijn naar mijn mening voor een groot deel onterecht, of staan in verhouding tot de risico’s die bij closed source horen. Ik vind je blog dus niet evenwichtig en daardoor niet aanmoedigen tot het maken van die objectieve afweging.

    Helaas ben je niet de enige die dit geluid laat horen. Dat is niet verwonderlijk, want de belangen zijn groot (waarbij ik overigens niet wil beweren dat jij in je mening door belangen wordt gedreven). Wat ik in de praktijk dus veel zie gebeuren, is dat men niet aan de objectieve afweging toekomt, omdat men door alle negatieve beeldvorming geen stap van het bekende pad durft te zetten. Al met al kost dat de overheid een kapitaal en hebben we geen idee wie er allemaal mee kan lezen.

    • Een objectieve afweging kan slechts gemaakt worden als beide zijden worden belicht. Open source werd de afgelopen dagen vaak als antwoord gegeven op ICT-trajecten binnen de overheid. De kern van mijn verhaal komt er op neer dat dit niet zonder meer het enige antwoord is, en dat open source op zichzelf staande uitdagingen met zich mee brengt. Net als closed source. Ik vind het belangrijk dat mensen die zich bezig houden met overheid, communicatie en ICT brede kennis hebben over dit onderwerp, alleen op basis daarvan, valt een onderbouwde afweging te maken. Was open source neergesabelt, dan is de kans groot dat ik een vergelijkbare blog had geschreven, om in dat geval de voordelen te belichten of juist de nadelen van closed source. Balans.
      Inderdaad, de stap naar open source wordt nog niet vaak gezet, en dat gebeurt al vele jaren niet. Om daarvoor alleen naar leveranciers te wijzen vind ik wat te gemakkelijk. Als onder andere de TCO van open source daadwerkelijk zo’n verschil maakt met closed source, zou het al breder zijn geadopteerd. Uiteraard speelt ‘the power of numbers’ daarin een rol, hoe meer over zijn, hoe groter het voordeel, hoe meer zullen deelnemen etc, maar het feit is dat we nog niet zover zijn en dat de afweging nog heel reëel en noodzakelijk is.

      • Annemarie, blijkbaar ziet jouw wereld er anders uit dan de mijne, als jij het signaal krijgt dat er een onevenwichtig enthousiasme aan het ontstaan is voor open source en het daarom tijd zou zijn om een blog te wijden aan de door jou beleefde nadelen.

        In mijn ogen slaat de balans in overheidsland op dit moment nog steeds ver uit naar de dominantie van closed source en is open source juist het tegengeluid. Naar mijn mening zou balans dus meer gediend zijn bij het aanmoedigen van dit tegengeluid, in plaats van het sprankje enthousiasme dat je hebt waargenomen gelijk weer de kop in te drukken met de standpunten van de gevestigde orde.

        Je beeld dat objectiviteit zal winnen van bijvoorbeeld de miljarden van Microsoft, vind ik wat naïef. Om een voorbeeld te noemen: met de overstap naar LibreOffice/OpenOffice kan een gemiddelde gemeente gemakkelijk tonnen gemeenschapsgeld per jaar besparen aan licenties. Maar helaas zijn er nog steeds grote leveranciers in de overheidsmarkt die er belang bij hebben om te weigeren om hun applicaties hiervoor geschikt te maken. Dat maakt zo’n overstap voor zo’n gemeente dus een stuk ingewikkelder en duurder, dan wanneer het in dit voorbeeld om een afweging tussen kantoorautomatiseringspakketten sec zou gaan.

  3. IIk denk dat de meeste opmerkingen op deze blog al het juiste hebben verwoord: Windows XP is geen overheidsspecifiek OS en bevat ook geen enkele aanpassing die door de leverancier is gemaakt op verzoek van de overheid. Omdat de overstap naar een nieuwere versie Windows net zo ver ligt als de overstap naar een ander OS is het om het even welke keuze daarin gemaakt wordt.

    Het feit ligt er wel dat er heel weinig actie ondernomen is om rekening te houden met een aangekondigd end-of-life. Om vervolgens een week voor deadline een hernieuwd contract met diezelfde leverancier aan te gaan waarmee niets anders is gewonnen dan opnieuw uitstel van een migratie is op zijn zachts gezegd heel naief! Temeer omdat deze leverancier voor veel geld veiligheidslekken (bugs) in haar software gaat oplossen dat zij in haar boeken al lang had afgeschreven. Ditzelfde klusje doet zij o.a. voor de Engelse en Chines overheid. Zelfde bugs, zelfde oplossing. Omdat er met publiek geld wordt betaald zou tenminste één overheid al mogen afdwingen dat die bugfixes ook openbaar beschikbaar komen zodat veel ouderen in Nederland met een stoffige Windows XP computer ook nog jaren veilig door kunnen.

    Wanneer er bij een overheid software in gebruik genomen dient te worden zal de overweging altijd zijn:Voldoet standaard software of is er binnen het overheidsdomein specifiek maatwerk noodzakelijk? Ondanks dat elke organisatie (publieke of private sector) aangeeft standaardapplicaties te willen blijkt toch altijd dat men anders is (denkt te zijn!) dan anderen en komt altijd de vraag naar maatwerk. In zo’n geval blijkt de keuze voor open source regelmatig voordeliger uit te vallen doordat er ‘geshopt’ kan worden bij meerdere uitvoerders voor de laagste prijs. Een overheidsorganisatie zal, zoals Davied al terecht opmerkte, meer de samenwerking met andere overheden moeten opzoeken om eenmalig het maatwerk aan te besteden en dus kosten laag te houden en te komen tot generieke overheidssoftware en standaarden.

    Wat betreft het beheeraspect van software en terugvallen op een leverancier in geval van veiligheidsrisico’s: Ik heb nog heel weinig organisaties meegemaakt die een Oracle of Microsoft op het matje roepen om gaten in haar software te dichten. Waardoor zou immers een platform als Windows XP al zo lang kunnen bestaan als het door ieder als onveilig wordt beschouwd? Vaker staan de afnemers gedienstig te wachten tot er nieuwe patches uitkomen met hopelijk de oplossing voor het probleem dat zij een jaar eerder indienden.

    In het geval van open source software zijn er keuzen: Er is meestal een commerciëel servicecontract bij een Enterprise Editie af te sluiten, er wordt een contract afgesloten met een Nederlandse System Integrator of de interne beheerorganisatie laat zich opleiden om deze ondersteuning te kunnen bieden. Is er geen contract afgesloten dan is vanwege de open broncode er gauw een partij gevonden die bereid is om in die regels code te zoeken naar een oplossing.

    We staan nog steeds aan het begin van een open revolutie waarin open source software en de daaraan gerelateerde organisaties meer volwassen worden en zich langzaamaan richten op domeinspecifieke oplossingen. Dit vraagt dus een investering van alle betrokkenen en met name de Nederlandse overheid zou hierin een leidende rol moeten pakken.

  4. Het onderwerp maakt duidelijk veel los. Goed om te zien, want dat betekent dat het leeft. Een van de zinnen in je reactie viel me op, Marjolein. Je schrijft dat jullie product zeer concurrerend is. Als je dat koppelt aan mijn blog, zijn we het volgens mij eens. Namelijk, in dat geval zal bij een afweging op TCO basis jullie product hoog eindigen en maakt het dus zeker kans ingezet te worden. Zo zou het m.i. ook moeten gaan, die eerlijke afweging is waar het mij om gaat. Of moet ik concluderen dat Loek en Marjolein open source als must zien?

  5. De grenzen tussen OpenSource en Closed Source zijn lang niet meer zo scherp als jij stelt. Ubuntu is een heel goede Linux distributie en je kan support krijgen van Canonical. Postfix is bijvoorbeeld een open source mailserver met een licentie van IBM (en zo garandeert IBM dat deze mailserver vrij van kosten blijft).

    Internet draait al meer dan 17 jaar op open source Apache HTTP server. Er bestaan miljarden applicaties gebaseerd op Java, PHP, MySQL, Postgresql, Ruby on Rails, Python, JavaScript. Hele frameworks, die klaar staan voor gebruik. De website van het Witte Huis is gebaseerd op Drupal. Business Process Management is heel volwassen in Java. OpenSource is veel verder geëvolueerd dan jij schetst.

    Oh ja, Windows 8 ondersteunt geen POP3 meer. Ik heb bij mensen Thunderbird (open source) moeten installeren om al hun e-mailaccounts te kunnen blijven gebruiken. Gelukkig is er keuze.

    @WouterDanes: GoogleDocs zou ik de overheid afraden in verband met privacy issues. Ik zeg niet dat Google zelf over de schouder meekijkt, maar wel dat ik het een langetermijn veiligheidsrisico vind. MS Office heeft al sinds jaar en dag security issues. Ik zou daarom juist Libre aanraden, temeer ook omdat deze haar documenten op welomschreven standaarden vormgeeft. Je documenten zijn zo op te halen in andere applicaties. Dat kan niet altijd gezegd worden van MS Office documenten.

  6. Er is denk ik een groot verschil tussen Kantoor Automatisering (KA) en closed of open source wanneer het gaat om applicatieontwikkeling / infrastructuur. Jouw argumenten zijn zeker steekhoudend wat betreft KA, dat wiel moet je gewoon niet zelf willen uitvinden. De defacto standaard op het moment in het bedrijfsleven is Google Docs of MS Office op MS Word of MacOS, ik snap het streven naar LibreOffice op Linux niet. 🙂
    Wanneer het gaat om softwareontwikkeling dan denk ik dat de open source community al bewezen heeft dat het de stack van closed source leveranciers ver voorbijgestreefd is.

  7. Annemarie,
    Je blog geeft een overzichtelijk rijtje vooroordelen over open source die closed source leveranciers graag gebruiken om (potentiële) klanten bang te maken voor een overstap naar open source. Helemaal verrast was ik dus niet om je nominatie/award voor “Microsoft Worldwide Alliance Partner of the Year” in je profiel te zien staan.

    • Hi Marjolein, dank voor je reactie. Ik ben benieuwd naar je weerleggingen van de punten die ik noem. Overigens werk ik als adviseur online media binnen het Ministerie van Algemene Zaken aan het beheer en de doorontwikkeling van Rijksoverheid.nl, een website volledig gebaseerd op het open source CMS Hippo. Dat staat vrij ver af van een closed source leverancier. De link met een aantal jaar geleden gewonnen award ontgaat me dus een beetje. 🙂

      • 1.) Of een ontwikkelaar zijn broncode geheim houdt (closed source) of niet (open source) zegt niets over de kenmerken van de software zelf. Open source software kan dus net zo goed specifiek zijn, of worden gemaakt.
        2.) Ook voor een open source pakket kun je (moet je) gewoon een beheerpartij in de arm nemen. Met dat verschil dat je bij open source vaak kunt kiezen en bij closed source niet.
        3.) Als het voor een closed source leverancier in de overheidsmarkt interessant is om specifieke functionaliteit toe te voegen, waarom zou dat bij een open source leverancier dan niet interessant zijn?
        4.) Klopt voor een deel inderdaad, maar zoals Davied al zegt, zijn er pakweg 1000 overheidsorganisaties en die zijn gewend stevige bedragen aan licenties af te dragen aan closed source leveranciers. Deze basis is breed genoeg om open source producten verder te ontwikkelen.
        5.) Bij een closed source community draait het slechts om 1 key speler: de leverancier. Als die wegvalt of niet bevalt, zit er niets anders op dan overgaan op iets anders, met alle kosten van dien. Bij open source kun je altijd nog nieuwe partners zoeken.

        Ik werk met het overheidsspecifieke open source product zaaksysteem.nl (hoewel het inmiddels ook buiten de overheid wordt gebruikt). Begonnen vanuit 1 gemeente, maar in korte tijd al met een leuk groepje deelnemers. De tco per gemeente verschilt in hoe actief deze deelneemt in de ontwikkeling, maar is zeer concurrerend met de closed source alternatieven.

        En voor wat betreft security. Tja, waar zou de overheid meer vertrouwen in moeten hebben: in de black box van een van een (vaak) Amerikaanse leverancier, of in een toetsbare broncode?

  8. In de reactie van Davied vind ik de zin “Er is nog veel te winnen in de samenwerking en uitwisseling tussen overheden” essentieel. Daar zit volgens mij inderdaad de grote uitdaging. Waarbij het feit of software open source is of een beperkte rol speelt. “Open source by default’ vind ik dus ook geen handig uitgangspunt (net zo min als “Closed source by default”. Onbevooroordeeld kiezen voor de best passende oplossing, zoals de auteur adviseert, lijkt me inderdaad de best passende strategie.

  9. Annemarie, je blog doet me terugdenken aan het onderzoek van de Algemene Rekenkamer enkele jaren terug. Blijkbaar is het een terugkomende discussie. Er zijn diverse voorbeelden van het gebruik van opensourcesoftware bij de overheid en het is niet slecht om je steeds de vraag te stellen of belastinggeld wel goed wordt gebruikt. Jouw aandachtspunten daarbij zijn terecht en kunnen niet vaak genoeg benoemd worden.

    Een aspect dat vaak terugkomt is de vraag hoe anders de overheid is dan andere organisaties. Ook in jouw blog is het een tweezijdig zwaard: de specifieke eisen maken het eindproduct zo bijzonder dat er geen gemeenschap voor is. De conclusie dat je daarom een standaardproduct uit de markt moet gebruiken, snap ik echter niet. Ik zie regelmatig dat overheden juist proberen (voor veel geld) die standaardproducten weer aan te passen aan hun eisen.

    Vaak is de vraag of dat nodig is. Als het gaat om werkpleksoftware, bedrijfsvoering, etc. dan zullen die eisen weinig afwijken van andere organisaties. Deze discussie begon deze keer vanwege dat soort software. Volgens mij maakt het weinig verschil of daarvoor je een standaard opensourceproduct of licentiesoftware gebruikt. Voor beide moet je het beheer regelen inderdaad, maar voor beide zijn ook voldoende diensten in de markt.

    Veel mensen hebben het idee dat opensourcesoftware wordt gemaakt door hackers en knutselaars op zolderkamers. Dat is de “community” waar ze het dan over hebben. Soms kan het die vorm aannemen, maar de idee van open source is beter te vergelijken met een cocreatie. Verschillende partijen kunnen toevoegen aan een gezamenlijk resultaat. De gemeenschap is dus een aantal partijen met hetzelfde belang.

    De vraag die je eigenlijk stelt in je blog is dan ook: welke partijen hebben een gezamenlijk belang bij overheidssoftware. Het antwoord: overheden. In meervoud. Het is gemakkelijk om in de volksmond te praten over “de overheid” en we willen ook werken naar een meer geïntegreerde (“één”) overheid, maar de praktijk is nog steeds dat er zo’n 1000 overheidsorganisaties zijn in Nederland … en nog een paar meer in het buitenland.

    Neem het voorbeeld van een zaaksysteem. Hoe specifiek is software om stapsgewijs zaken af te handelen binnen een gemeente? Waarschijnlijk kun je veel componenten gebruiken uit andere software, mits die componenten beschikbaar zijn natuurlijk. Vervolgens zijn er 400 gemeenten die allemaal min of meer dezelfde toevoegingen hebben. Zou het niet handig zijn als ze die extra componenten kunnen uitwisselen en gezamenlijk afspraken maken over het beheer?

    Veel opensourcesoftware wordt al gebruikt binnen de overheid, juist omdat het plooibaar is en aangepast kan worden aan specifieke eisen en omdat het uitgewisseld kan worden tussen overheden. De uitdaging is vaak het vinden van een goed model om met meerdere partijen het beheer en de doorontwikkeling te regelen. De wens is om iets “van de plank” te kopen en er dan mee klaar te zijn. Software is echter bijna altijd maatwerk.

    Ik ben het dus helemaal eens met je conclusie: kies voor de best passende oplossing en kies voor flexibiliteit. In elke situatie zal de afweging voor open source of licentiesoftware een andere zijn. Mijn oproep is om verder te kijken dan alleen het product dat in het schap ligt. Er is nog veel te winnen in de samenwerking en uitwisseling tussen overheden. Dat is maatwerk van een ander soort, maar in iedere geval maatwerk dat kleine innovatieve bedrijven in Nederland stimuleert.

    Deze reactie is ook gepubliceerd op http://ambtenaar20.ning.com/profiles/blogs/overheid-en-open-source-een-open-deur

    • Ha Davied! De ambitie die je beschrijft is heel mooi, en nastrevenswaardig. Overheden an sich zijn natuurlijk een (het zij kleine) community. Het is jammer dat dergelijke vormen van samenwerking nog niet echt van de grond komen. Waar zou dat mee te maken hebben denk je? Toch nog teveel eilandjes?

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s