Deel dit artikel
-

Octrooicentrum omarmt open source-software

Het Octrooiencentrum Nederland (OCNL) stapt voor een groot deel over op open source-software. Hiermee is het de eerste overheidsorganisatie die overstag gaat en navolging geeft aan het actieplan ‘Nederland Open in Verbinding’.

Het was staatssecretaris Heemskerk van Economische Zaken die woensdag de nieuwe op open source gebaseerde website van OCNL lanceerde. Het octrooicentrum gebruikt onder meer het open source content management systeem Joomla.

Staatssecretaris Heemskerk noemt hetOCNL op dit gebied een ‘koploper’ en hoopt dat hiermee ook andere overheidsorganisaties gestimuleerd worden het actieplan te implementeren.

In het actieplan is een belangrijke rol weggelegd voor open standaarden en open source software. Een aantal concrete maatregelen moet ervoor zorgen dat overheden vaker open standaarden en open source-software gaan gebruiken. Het kostenplaatje is een belangrijke factor in het plan, de open source-software zorgt voor minder hoge kosten voor de overheid. Tegelijkertijd maakt open source-software de overheid ook minder afhankelijk van leveranciers.

De volgende stap bij OCNL wordt gezet in de kantooromgeving (inclusief desktop) en het relatiebeheersysteem van de organisatie. Dit moet eind 2009 ook op open source zijn gebaseerd.

Deel dit bericht

10 Reacties

R van Zandwijk

Mwah, Ik zou er persoonlijk niet voor gaan, open-source heeft vaak nog beperkingen / lekken.Vooral een website met een publieke functie zou hier gevoelig voor kunnen zijn. R.

Rick

Gossie, en closed software heeft geen beperkingen / lekken? Met open software zijn beperkingen / lekken eenvoudiger aan te pakken, iedere programmeur met kennis van het systeem kan er mee aan de slag. En dus niet uitsluitend de leverancier. Closed of open, beide hebben hun voor- en nadelen. De ene is echt niet beter dan de andere, het is anders.

Stefan de Konink

Nu nog alles afwijzen wat op een software patent lijkt en we kunnen echt blij worden.

Jan Willem Schermerhorn

Ik heb persoonlijk andere ervaringen. Veel bedrijven stappen juist van opensource af. Hier zijn een talloze redenen voor. Opensource blijf links of rechts om een techneuten aangelegenheid waarbij uiteindelijk niemand op aangesproken kan worden. Het is leuk en nuttig om dingen te ontwikkelen maar op het moment dat zoiets daadwerkelijk onderdeel van het bedrijfsproces gaat wprden brengt het vele risico's met zich mee. Denk aan kennis, verantwoordelijkheid,responsetijden etc. Je beroepen op : Het is opensource er is altijd wel iemand die het weet, is killing voor bedrijven.

Anton van der VOorn

Het is een oude discussie. Mijn persoonlijke zakelijk ervaring is dat open source of closed source geen uitgangspunt kan zijn bij een selectie van een pakket. Op basis van een lijst met relevante selectiecriteria maak je een keuze voor de applicatie. Misschien is open source een randvoorwaarde in het geval van OCNL. Simpel: gratis software betekent nergens aanspraak op kunnen maken in geval van disfunctioneren. Als dit risico de continuiteit van een organisatie niet bedreigt is dat geen probleem. Als de toepassing bedrijfskritisch is ben ik van mening dat open source niet gekozen moet worden.

Bruce

Anton, ik kan mij volledig vinden in je opmerkingen aan het begin van je commentaar. Bij het verwerven van Open Source Software dient dezelfde criteria te worden genomen als bij de verwering van welk andere vorm van software dan ook (beslissingskader, algemene kwaliteitstoets, functionele toets, implementatiestrategie etc.). Maar hoe kom je vervolgens tot de conclusie in je laatste zin dat "open source software niet moet worden gekozen als een toepassing bedrijfskritisch is"?  Open Source is een licentievorm (zie OSD criteria) en in de volksmond een ontwikkelingsmodel waarbij community involvement een grote rol speelt (al trek ik deze twee interpretaties liever apart). Als je een bepaald Open Source Software product een bedrijfskritische rol wil geven, dan sluit je met een gerenommeerde service partner een support contract af waar je verscheidene eisen in afdwingt. Pas als dat niet mogelijk is, dan schuif je het betreffende product opzij. Het is belangrijk om hier elk product individueel te bekijken en niet te generaliseren. Dit kan overigens ook worden gezien als een reactie op Jan Willem Schermerhorn's commentaar. Zie onder andere het document "Het verwerven van (open source) software" van OSOSS (tegenwoordig programmabureau NOiV), te downloaden via http://www.ososs.nl/files/Verwerven_van__open_source__software_-_tekst.pdf

Anton

@bruceAls de applicatie werkelijk in de geest van open source wordt doorontwikkeld en niet door een commerciele softwareontwikkelaar ondersteund wordt (zoals je bij een aantal linux-varianten wel tegenkomt), dan is er niets en niemand die in een Service Level Agreement de verantwoording neemt voor het goed functioneren van de software. Bij commerciele softtwarepakketten is er een financiele stok achter de deur om voor klanten, die voor de continuiteit van de organisatie afhankelijk zijn van de applicatie, oplossingen te bieden. Bijvoorbeeld maatwerk hotfixes. Dit zie ik niet gebeuren bij open source projecten.

Catharina

@Anton: dat hoef je ook niet meer te zien gebeuren, want dat is er al lang. Kijk maar eens bij organisaties als Novell, RedHat en Canonical.

Bruce

@AntonBedankt voor je reactie. Zoals ik eerder opmerkte is Open Source allereerst een licentiemodel en daarnaast een ontwikkelingsmodel dat beter bekend staat als het bazaar-model (The Cathedral and the Bazaar, Eric S. Raymond). De geest van Open Source zoals ik dat zie komt niet overeen met jouw interpretatie. De kernwoorden waar ik bij Open Source aan denk zijn openheid, transparantie en flexibiliteit.  Als je luistert naar leiders binnen de gemeenschap als Bruce Perens (o.a. Open Source Initiative) en Richard Stallman (o.a. Free Software Foundation) dan zie je dat zij allen spreken over het vormen van een ecosysteem om de software heen. Zie bijvoorbeeld de panel discussie met Perens, Stallman en Shuttleworth op de World Summit for the Information Society in Tunis op 18 November 2005 ( http://video.google.com/videoplay?docid=-694927630239078625 ). Denk bijvoorbeeld aan de wijze waarop Nederlandse gemeenten samenwerken bij de inrichting en doorontwikkeling van hun websites in de vorm van TYPO3gem ( http://www.typo3gem.nl/ ). De omschrijving op de website zegt genoeg: ?De leden bepalen samen welke functionaliteiten (in welke volgorde) zij nodig hebben voor hun e-Overheid. Met kennis en inzet van leden (en dienstverleners) worden daarvoor specificaties opgesteld. Met bundeling van financi?le middelen (en contributie) worden wensen op dit gebied aanbesteed. De gemeenten werken ook samen bij het beheer van hun websites (helpdesk) en bij het in gebruik nemen van de meer geavanceerde onderdelen van TYPO3.? Globaal zie je dit model op meerdere plekken terugkomen. Kijk bijvoorbeeld naar de Apache Foundation ( http://www.apache.org/foundation/members.html ) of de Eclipse Foundation ( http://www.eclipse.org/org/ ). Wellicht is dit model ook te vergelijken met standaardisatie consortiums als het W3C en OASIS. Ik denk dat we de komende jaren meer en meer deze kant op zullen bewegen, waarbij organisaties met een gezamenlijke doelstelling samen komen en projecten aansturen in samenwerking met dienstverleners. Dit model van samenwerking zal naar mijn mening onder andere leiden tot meer innovatie en effici?ntie.

Arjen

Beste Anton,Om curieuze redenen lijkt het alsof jij denkt dat je garantie hebt (as in: de leverancier aansprakelijk kan stellen bij bugs) op software omdat je geld hebt betaald voor de licentie. Ik zou je licenties maar een laten lezen door een jurist en je laten uitleggen wat er in staat. Vrijwel geen enkele software komt met garantie, voor echte support moet je een support contract kopen. Geen verschil tussen open- of closed source. Met vriendelijke groet,Arjen

Plaats een reactie

Uw e-mailadres wordt niet op de site getoond