Het lijkt maar niet te lukken open source onderdeel te maken van het ict-beleid. Eind vorig jaar zagen we de constatering van de staatssecretaris en nu weer het bericht dat gemeente Amsterdam zich in eerste instantie niet gaat richten op open source. Gemeente Heerenveen maakte recentelijk ook een stap met vervanging van Open Office door Microsoft Office. Achtergrond: gebrek aan open standaarden voor integratie met andere producten. Dit laatste heeft Microsoft nooit tegengehouden, er waren altijd wel partijen die koppelingen tot stand brachten. Is het mogelijk deze impasse te doorbreken, willen we veranderen, is het gebrek aan kennis, open standaarden of zijn het de kosten (total cost of ownership)? Mogelijk zijn deze vragen beter te beantwoorden door je te richten op ict als geheel, waarbinnen open source en open standaarden wel een belangrijke rol kunnen spelen.
In het verleden heb ik veel pakketselecties gedaan, onder andere van erp-systemen en document/workflow management-systemen. Ik heb dit bijvoorbeeld gedaan voor de overheid, zand en grindwinning, IPR-rechtenafdracht, financiele instellingen en een productiebedrijf voor fietssloten. De kwaliteit/prijs-verhouding is altijd het voornaamste punt van afweging, maar niet minder belangrijk zijn de continuïteit van de leverancier en ervaring van anderen met het geleverde product. Kwaliteit wordt dan uitgedrukt in functionaliteit en technische aspecten met daarbij parameters als schaalbaarheid, performance, etc. Als we verder in detail gingen, werd onder technische aspecten ook de integratie van het product met andere producten meegenomen, waarbij open standaarden voorop stonden. Continuïteit van een leverancier werd uitgedrukt in zijn financiele situatie en de kernactiviteit van die leverancier. Richt de leverancier zich op productontwikkeling of heeft hij daarnaast ook implementatieteams en wat is de mate van investering in productontwikkeling? Ervaringen van anderen zijn ook altijd van groot belang gebleken. Zijn andere klanten tevreden met het product, wat is hun ervaring bij de implementatie, etc.
Prijs wordt door alle leveranciers anders uitgedrukt. Het is daarom altijd zaak om te kijken naar de totale kosten van installatie, implementatie en gebruik van een product, de total costs of ownership. Hier spelen jaarlijks terugkerende licentiekosten natuurlijk wel een rol, maar veelal zijn de implementatie-, beheer- en onderhoudskosten hoger. Vervanging van leveranciersproducten door open source gaf daarmee in eerste instantie slechts een beperkte besparing. Op langere termijn moet vooral gekeken worden naar de beheer- en onderhoudskosten.
Zo zijn er diverse factoren die een rol spelen bij de keuze van een softwareoplossing. Ook van groot belang is de concurrentie op de markt voor een bepaald product. Open Office is concurrent van Microsoft Office en heeft geen licentiekosten. Daarnaast is het al gewoon om open source-content en document management-systemen in te zetten. Ook zijn er open source-producten voor integratie en een open erp-oplossing is ook al een aantal jaren voorhanden. Voor dit soort producten hebben we alleen implementatie-, beheer- en onderhoudskosten. Je zou denken dat vele sofwarehuizen kennis investeren in deze open source-producten om zo de markt beter te kunnen bedienen. Of mogen ze dit niet als ze ook Microsoft gecertificeerd zijn? Ik neem aan de de eurocommissaris mededinging al lang naar dit soort aspecten heeft gekeken. Is het gebrek aan kennis en veranderingsbereidheid van onze eigen ict-medewerkers? Veel ict'ers hebben zo hun persoonlijke voorkeur voor een ontwikkelomgeving: elk probleem is een spijker en de oplossing is altijd een hamer. De argumentatie is dan ook vaak dat J2EE ook open source is. Ik heb meegemaakt dat ict'ers vaak het probleem niet eens onderkennen en niet gaan zoeken naar open source-code voor de oplossing, maar vinden dat ze het zelf sneller en ook beter kunnen ontwikkelen met grote kostenoverschrijding en langere doorlooptijd als gevolg.
Een grote succesfactor bij de verspreiding van een open source-product als Linux is de bereidheid van een leverancier om zogenaamde shrink-wrapped oplossingen te bieden. Red Hat is een bekend voorbeeld. Deze zijn met beperkte inspanning te installeren en daarmee snel inzetbaar. Kennelijk ontbreekt dit voor een groot aantal open source-oplossingen. Wat is het Nederlandse systeemhuis dat de marktleider is in Open Office-installaties? Heb je direct een naam beschikbaar? Voor mid office-oplossingen van gemeenten denken we direct aan Exxelence, maar is dit daadwerkelijk open source wat ze leveren? Dit zou betekenen dat ook anderen deze open source kunnen installeren, maar dat is niet het geval.
Op een grotere schaal dan een individuele overheidsorganisatie is het van belang om te komen tot open source-implementaties. Dit versterkt de concurrentie tussen systeemhuizen, verhoogt de kennis bij ict'ers en geeft daarmee lagere kosten. Het is dus in het belang van de Nederlandse overheid om toch over te gaan op open source. Ik zou zeggen dat een reorganisatie geen oplossing is om de impasse te doorbreken rond open source, maar dit is kennelijk ook niet de bedoeling als we gaan reorganiseren. Er zal wel een gedegen, duur advies liggen dat aangeeft dat reorganisatie tot kostenbesparing en -beheersing leidt. Mij lijkt dat het probleem wel organisatorisch van aard is. Ik zou hier aan toe willen voegen dat het ook kennis is die ontbreekt en de openheid van mensen om andere wegen te bewandelen, maar vooral een inhoudelijke achterstand bij management op techneuten. Het wordt tijd om een overzicht te krijgen met al deze factoren die een rol spelen bij open source en vanuit politiek en ook economisch perspectief te kijken hoe deze factoren zijn gehanteerd.
“Het wordt tijd om een overzicht te krijgen met al deze factoren die een rol spelen bij open source en vanuit politiek en ook economisch perspectief te kijken hoe deze factoren zijn gehanteerd.”
Hopelijk helpt mijn afstudeer onderzoek in deze discussie. Hierin worden ontwerp principes beschreven om open source mee te nemen in het software keuze traject.
Het beantwoord dus de simpele vraag: hoe koop ik iets dat gratis is?
Dit gaat verder dan alleen de kreten “software is software” en “kijk vooral naar TCO”.
Strategische visie is hierbij een belangrijk onderdeel, maar ook hoe je zo’n veranderingsproces inricht in een organisatie. Met de ontwerp principes kunnen organisaties hun “inkoop” proces zelf aanpassen om rekening te houden met open source.
In juni 2010 is de presentatie van dit onderzoek op de Technische Universiteit van Eindhoven.
@Maurice
Stuur me vast een kopie! Ik ben in Oostenrijk bezig om een gemeente te overtuigen, dat betekent een extreem lange adem hebben.
@Wout,
Klopt, mensen staan te weinig open voor veranderingen, ik ben boven de 50 maar verbaas me over de starheid van mensen die veel jonger zijn. Is waarschijnlijk genetisch, mijn moeder van 89 heeft pas een nieuwe PC met Win7 gekocht en heeft er enorm veel plezier mee.
Ik denk persoonlijk dat Open Source met grote reserves moet worden bekeken. Het is naar mijn mening ontstaan als antwoord op betaalde software en niet als beter alternatief voor de eindgebruiker. Daarbij vindt ik het bizar dat je software per definitie al wil aanschaffen, omdat je het wil wijzigen. Tenslotte leert mijn ervaring dat het communicatie model bij Open Source software veel te vrijblijvend is. Het gebeurt te vaak dat modules op zich wel werken, maar niet in samenhang, vanwege verschillende toegepaste ontwikkelmethode. Ik denk dat Open Source vooral wordt bekeken vanuit de koopmansgeest, niet vanuit de beste funktionaliteit. Het wordt de doodslag voor de betaalde ontwikkelaar in het westen. We moeten gewoon weer gaan betalen voor goede oplossingen, ipv ons heil in Open Source te zoeken.
Persoonlijk vind ik open source een goede zaak.
Al was het maar om software-ontwikkelaars flink onder druk te zetten. Dankzij open source software zijn de kosten van software niet uit de pan gerezen.
GeenUbuntuFanMeer
>Het is naar mijn mening ontstaan als antwoord op >betaalde software
Fout, het is ontstaan als reactie op software die programmeurs niet mogen bestuderen, repareren of uitbreiden.
Rechtstreeks van de Free Software Foundation:
“we encourage people who redistribute free software to charge as much as they wish or can.”
http://www.gnu.org/philosophy/selling.html
>Het gebeurt te vaak dat modules op zich wel werken, >maar niet in samenhang,
Vandaar dat er distributies ontstaan, Red Hat, Ubuntu,…
>Het wordt de doodslag voor de betaalde ontwikkelaar in >het westen.
Een open source programmeur is zoals een advocaat,
iemand die erg lang iets technisch ingewikkeld heeft bestudeert en die expertise op de markt aanbiedt.
Iedereen mag zichzelf verdedigen in een rechtszaak, maar dat betekent niet dat altijd dat een goed idee is.
Je laat het beter over een specialisten, die je betaalt.
Johan van de Merwe, ik ben het mee u eens.
“Dankzij open source software zijn de kosten van software niet uit de pan gerezen.”
Zoveelste losse kreet.
@ Johan van de Merwe
Open Source software wordt inmiddels ontwikkeld door programmeurs die gewoon betaald worden, dus dat argument gaat niet op. Ik werk met open source software, verdien mijn brood daarmee, wordt betaald voor de oplossingen die ik aandraag of maak.
Als je problemen hebt met modules die niet samen werken kun je dat laten maken, dat doen inmiddels veel mensen, daar leven programmeurs van.
Samenvattend ben je niet vertrouwd met dat “verdienmodel” maar als je een beetje moeite doet kun je dat leren. Dat heb ik ook gedaan.
Daarnaast heb ik software gekocht nadat ik de eenvoudigere open source variant een tijdje gebruikt had en daar erg enthousiast over was, het een sluit het ander dus niet uit.
Om even wat onzin met argumenten tegen te spreken:
http://en.wikipedia.org/wiki/Open-source_software
http://en.wikipedia.org/wiki/Free_software
Open source/free software bestaat sinds het ontstaan van de computer. Het is dus onzin dat open source ontwikkeld is als tegenhanger, er was bij het ontstaan van de computer helemaal geen tegenhanger.
Verder wordt er geschat dat er zo’n 60 miljard dollar per jaar mee wordt bespaard, wat toch een redelijk bedrag is.
Mocht open source de doodslag zijn voor de betaalde programmeur in het westen, dan zal closed source daar niets aan veranderen. Geen mens die veel geld gaat betalen voor closed source uit het westen wanneer je deze functionaliteit voor niets kan krijgen uit het bv. het oosten. We importeren nu ook al van alles en nog wat uit China, dat zal met software echt niet anders gaan. Leg de focus op maatwerk en kennis, dan wordt het ineens een heel ander verhaal en heb je een goed belegde boterham.
Frank zei: “Leg de focus op maatwerk en kennis, dan wordt het ineens een heel ander verhaal en heb je een goed belegde boterham.”
Helemaal mee eens. De tijd zal het leren. Een betoog:
Het draadje : “dit jaar is het jaar van Linux!” staat geloof ik al meer dan drie jaar op computable.nl en ik geloof daar niet in. Er staat nergens geschreven dat een “open source revolutie” in x jaar moet gebeuren.
Adoptie van de “open source” filosofie houdt wat mij betreft meer in dan alleen van software “leverancier” veranderen. Willen we echt adoptie, dan moet er zowel bij de klant alsmede bij “de leverancier”, wat in de gedachten gang veranderen.
Deze verandering lijkt mij meer een sociaal proces en die duren nu eenmaal lang. Gelukkig is dit proces al wat jaren bezig en de uitwerking daarvan wordt steeds merkbaarder. Dit type discussie, welke telkens in alle felheid los barst, is daar een goed voorbeeld van. Het zijn twee botsende denkwerelden. Van die twee, wordt er eentje steeds beter uitgewerkt en gearticuleerd.
Daarnaast merk ik op, dat in de afgelopen decennia, ook technisch ontzettend veel werk is verzet in de open source wereld. Realistisch gezien, was het bijvoorbeeld 10 jaar geleden onmogelijk, om een Linux desktop groots uit te rollen. Linux is ondertussen volwassen. En dus wordt dit nu daadwerkelijk gewoon gedaan. De overstap is meer dan vroeger, alleen nog maar een kwestie van: onbekend maakt onbemind.
Ook werpt het jaren lange gestoei met bedrijfs modellen zijn vruchten af. Er is namelijk een model ontstaan, waarvan ik verwacht, dat mensen zullen laten zien dat er (veel?) geld mee te verdienen is. Daarnaast denk ik dat dit model tegelijkertijd goedkoper is voor de klant, dan het toepassen van monopolistische one-size-fits-all proprietary software. Let wel, voor grote projecten. Niet perse voor consumenten “producten”.
Het gaat om de advocaat/bouw-sector bedrijfs modellen. Deze worden nu al toegepast en het succes zal anderen aansteken, zo leert ons de marktwerking. De markt moet uitwijzen of deze modellen op de lange termijn echt stand houden. Op dit moment is het aan ieder voor zich, om te bepalen hier aan mee te doen of niet. Kwestie van religie? Sociaal-liberaal of toch maar een plutocracy? Het is aan u!
Het toepassen van hybride systemen wordt steeds moeilijker. Software platformen worden weer dusdanig verticaal geïntegreerd, dat wisselen van componenten steeds moeilijker wordt gemaakt. Dit ontstaat mede dankzij de druk van FLOSS, aangezien de stack nu wel tot op GUI niveau geïntegreerd moet worden, om nog geld te kunnen verdienen. Op een xml koppeling hier en daar nagelaten, kan van echte hybride systemen op termijn geen sprake meer zijn. Ironisch genoeg, werkt dat in het voordeel van open source. Immers hoe meer lockin, des te aantrekkelijker wordt de vrijheid die FLOSS biedt.
Deze verticale integratie staat haaks, op wat de bouw en onderhoud van grote software projecten goedkoper zou kunnen maken. Namelijk grote delen van vrije losse FLOSS componenten in combinatie met “uurtje factuurtje” maatwerk. Oftewel het bouw sector model.
Verdeling van arbeid zorgt al eeuwen voor economische vooruitgang, ook dat komt uit de economie boeken. In tegen stelling tot 20 jaar geleden, is software tegenwoordig zo complex, dat geen bedrijf in zijn eentje alles kan overzien. Zie daarvoor de lange lijst met gefaalde software projecten elders op deze website. Ook het onvermogen van bepaalde software leveranciers, om ondanks gigantische jaarlijkse R&D budgetten, veilige software te maken is tekenend. De oplossing voor complexiteit, is modulariteit en dat is ook al eeuwen bekend.
Daarom ligt de oplossing niet in de bestaande “software retail industrie”, maar in verdeling van arbeid, zowel technisch (FLOSS) als organisatorisch (het bouw sector model).
Dit model houdt in dat er “aannemers” moeten komen die goed zijn in het managen van de iteratieve software bouw en het aanspreek punt zijn voor de klant. Daarnaast moeten er architecten bureau’s zijn die samen met de aannemer, oplossingen kunnen ontwerpen op basis van vage klant wensen. Die keuzes kunnen maken uit FLOSS bouwblokken en die specificaties kunnen opstellen voor nieuwe FLOSS componenten. Ook software huizen die goedkoop en snel FLOSS bakstenen kunnen maken (of uitbreiden) zijn nodig. Daarnaast dienen er bedrijven te komen die gespecialiseerd zijn in het leveren van support aan de eindgebruikers. Een goede relatie met “de community” is voor ieder essentieel.
Hoe meer specialisten op deze manier gaan samen werken, des te groter het netwerk effect van de vrije FLOSS bouwblokken en des te competitief en lokaal de markt van software oplossingen wordt. Daarbij draait het uiteindelijk (en wordt er betaalt!) om zo snel mogelijk de gewenste functionaliteit voor de klant te realiseren. En dan gaat het dus niet meer om het uitbuiten van het intellectuele eigendom en copyright van de bakstenen. Want dat is voor de klant en de sector zinloos.
De inherente voordelen van open source (onafhankelijkheid, kwaliteit, kosten besparing en beveiliging) verkopen zichzelf. Voor specialisten is het nu een kwestie om durven te veranderen van de “software retail industrie” naar een bouw sector. En dat mag best een paar jaar duren…
Nog even een (oud) statistiekje: 40% van alle bedrijfs servers en 20% van de bedrijfs applicaties in 2008 is open source (Bron http://statline.cbs.nl/StatWeb/publication/?VW=T&DM=SLNL&PA=80337NED&D1=0-3,11,15-16,66-83,92-93,96,99-105&D2=a&D3=0,l&HD=100223-0043&HDR=G1,G2&STB=T). Ik wacht met spanning de cijfers af van 2009 en 2010. Verder benadruk ik dat alles hierboven mijn eigen mening is en niet verward moet worden met het onderzoek wat ik op dit moment uitvoer. Op basis van mijn huidig onderzoek zijn deze stellingen namelijk niet te maken, vanwege het simpele feit dat de inhoud van dit bericht niet het onderwerp van mijn huidig onderzoek is.