Open Source toepassen, waar kun je het beste op letten?

[Milo van der Linden]

Dankzij het plan Heemskerk is Open Source ook bij de overheden op het netvlies gekomen. Dit is in principe een goede zaak. Er zijn echter wel een aantal valkuilen. De leveranciers beseffen ook heel goed dat spreken over Open Source voordelen kan hebben in het commercieel invulling geven aan projecten. De term "Open Source" past hiermee in het rijtje "Duurzaam", "Groen" en "Innovatief"

Om te voorkomen dat je slachtoffer wordt van het simpel volgen van een modekreet zijn er bij het kiezen voor Open Source zijn een aantal zaken om goed op te letten:

"Onze software gebruikt/is gebaseerd op Open Source"

Dit is een veelgebruikte truc. Softwareleveranciers misbruiken de term Open Source om hun eigen, gesloten software te versterken. Veelal staat echter in de offertes, de algemene voorwaarden of de contracten dat het eigendom van de totaal oplossing bij de betreffende leverancier blijft. Dit resulteert dan uiteindelijk in dat gene waar Open Source juist tegenwicht aan probeert te geven: een vendor lock in. Je zult in dit geval vaak voor een oplossing toch afhankelijk blijven van die ene leverancier. Lees dus altijd de contracten etc. goed door, maak jezelf er zeker van dat je een vendor lock in uit de weg kunt gaan door voor de betreffende partij en de betreffende oplossing te kiezen. Deze truc heeft nog een vervelend karakter. Open Source communities zijn kwetsbaar en bestaan ook gewoon uit mensen die hun brood willen verdienen. Als teveel partijen enkel gebruik maken van Open Source zonder ooit de community te helpen, dan sterft een Open Source project uit. Hoe kun je Open Source communities helpen? Dat kan op heel veel verschillende manieren!

Beantwoord bijvoorbeeld in de publieke fora af en toe eens een gebruikersvraag. Je ontlast hiermee de ontwikkelaars die daardoor met het ontwikkelen van het product bezig kunnen blijven zonder te vaak te worden afgeleid.

Vertaal documentatie! Je maakt hiermee het open source product toegankelijker, maar maakt jezelf ook het product eigen.

Meld fouten en problemen in de publieke omgeving die daarvoor is ingericht. Op die manier ontstaat een duidelijke plaats met alle ins en outs van het product.

Help mee met het schrijven van code, alleen voor de die-hards uiteraard.

Sponsor een Open Source product financieel

Geef maatwerk code met een generiek karakter die is opgebouwd in een intern project terug aan de community

"Open Source is linux en vaak niet geschikt voor Windows"

Dit klopt in sommige gevallen, maar je zult je verbazen wanneer je ziet hoeveel Open Source producten écht op allerlei verschillende platformen draaien. Wat wel belangrijk is en wat mogelijk is het voorkomen van hoge beheerskosten. Kies dus altijd voor Open Source oplossingen die ofwel zeer goed gedocumenteerd zijn ofwel passen op het kennisveld van de betreffende service organisatie

"Open Source, dus gratis"

Nee. Open Source bestaat vooral dankzij een nieuw businessmodel: In plaats van het uitgeven van licenties wordt er door implementatie-partijen geld verdient met het verlenen van opleidingen, ondersteuning en implementatie. Zorg er voor dat bij Open Source projecten vooraf duidelijk is welke kosten er gemaakt dienen te worden voor een goede implementatie. Vergelijk aanbiedingen van verschillende partijen!

"Onze software is Open Source want de broncode is beschikbaar"

Pas op! Open Source werkt alleen wanneer een project écht actief is. Immers, wanneer de broncode niet wordt onderhouden, of het aantal leden van een community is klein, dan is de kans op verbetering en uitbreiding in de toekomst gering. Het risico is dan vaak dat je een product hebt gekozen waarvoor je later zelf een organisatie moet inrichten om deze te onderhouden. En dat is geen eenvoudige opgave. Vuistregel is dat je altijd dient te onderzoeken of een Open Source project een actieve community heeft (ga op zoek naar het aantal en de datums van de meest recente acties) regelmatig wordt gereleased (controleer de datums van de meest recente versie) beschikt over de juiste middelen (Is er een omgeving om fouten te rapporteren? Is er een forum? En een mailinglijst?) en volg vooral je gevoel!

Leesvoer:

"Het ontwikkelen van Open Source-software is vaak een internationale onderneming. Een van de meest inspirerende zaken is de manier waarop documentatie heel snel wordt vertaald in andere talen, ongeacht in welke taal deze in eerste instantie is opgesteld. Ik ben enorm blij dat ‘Producing Open Source Software’ nu dankzij SURF en Kennisnet beschikbaar is in het Nederlands, niet alleen online maar ook in een mooie papieren versie.”

http://www.surfnet.nl/nl/nieuws/pers/Pages/SURFenKennisnetpresenter...

[Milo van der Linden]

@PerlMonger, mijn ervaring gaat niet zo ver terug, maar de Open Source beweging in GIS, mijn taakveld, bestaat al erg lang; in 1982 werd GRASS open source en 1994 werd het OGC opgericht.

Binnen de open source geospatial beweging, verenigd onder www.osgeo.org is het verloop minimaal te noemen. Dat is een luxe, dat besef ik goed.

Ik weet niet of het komt omdat osgeo een van de oudste, maar ook een van de meest stabiele open source omgevingen is, maar het werkt. En met name doordat de bedrijven die er mee verbonden zijn commerciële belangen hebben. Belangen die ze verdedigen en daarmee de community levend houden zonder dat daarmee anderen de kans wordt ontnomen de software te gebruiken, deel te nemen of zelf business te bedrijven met de software.

Zonder een business model werkt opensource niet in mijn optiek. Ook bij wordpress en joomla wordt indirect goed verdiend. En dus is het belang om Joomla en wordpress stabiel en toekomstvast te houden groot.

[Milo van der Linden]

@PerlMonger Helemaal met je eens! Vandaar ook mijn lijst met valkuilen. Ik wil in deze blog vooral wijzen op de voordelen van goed omgaan met Open Source:

1 - Je stapt op de juiste trein door goed vooronderzoek
2- Je helpt als "klant" de trein rijdend te houden door op de juiste manier met de community om te gaan.

Op die manier kennen Open Source projecten in mijn optiek geen verliezers en heeft iedereen baat bij elkaars aanwezigheid.

[Jeroen van Rest]

Open Source is vaak minder interessant dan Open Standaarden. Het is vaak niet erg als een product Closed Source is, als het maar communiceert via Open Standaarden. Dan kun je het bijvoorbeeld makkelijker vervangen door een ander product.

[Milo van der Linden]

@Jeroen, dat ben ik deels met je eens. Open standaarden vloeien vaak voort uit defacto standaarden. Veel andere open standaarden zijn nooit verder gekomen dan dikke epistels met theorie zonder daadwerkelijke implementatie. Een mooi voorbeeld is kml, het bestandsformaat achter Google Earth en Google Maps. Dit is een standaard geworden doordat veel mensen kml gingen gebruiken doordat het open en toegankelijk was.

De juiste combinatie van open standaarden en open source zal dus nog meer flexibiliteit geven.

[Jeroen van Rest]

@Milo, als je naar MS Word documenten kijkt, dan waren die wel een defacto standaard, maar niet een open standaard. Gevolg is wel degelijk vendor-lock-in. Ik ben verder ook geen specialist, maar haal mijn kennis in deze, ook vooral van openbare bronnen: http://en.wikipedia.org/wiki/Open_standard :-)
KML is idd een goed voorbeeld van een open standaard. NB ik zeg niets over hoe de open standaard tot stand is gekomen.

[Milo van der Linden]

Het probleem met MS Word documenten is het licentiemodel dat Microsoft op dat document formaat heeft. Microsoft heeft het open beschikbaar stellen van het technisch formaat van Word documenten tot in rechtzalen bevochten.

[Hans Bos]

@Milo: Het bestandsformaat voor MS Word documenten is als 'vrije specificatie' gratis beschikbaar voor iedereen. Om de toegang tot het formaat nog onafhankelijker van Microsoft te maken is bijvoorbeeld ook beschikbaar via de British Library: http://www.bl.uk/dp/formats en via de US Library of Congress: http://www.digitalpreservation.gov/formats/intro/specifications.shtml.
Daarmee zijn de (oude) binaire formaten van Microsoft Office (doc, xls, ppt) nog geen open standaard, maar wel digitaal duurzaam en vrij voor iedereen toegankelijk en te gebruiken. Zo voorkom je ook een potentieel vendor lock-in.

[Jeroen van Rest]

@Hans & @Milo: Maar het punt voor bovenstaand artikel blijft dan dat Open Standaarden -hoe ze ook zijn ontstaan- vaak relevanter zijn dan Open Source. Na een korte Google query (http://www.google.nl/search?q=open+source+versus+open+standards) kom ik ook op een artikel wat dit punt onderstreept: http://news.cnet.com/2010-1071-995823.html

[Simon de Ligt]

@Milo: Leuk artikel. Ik zou zelf de titel anders hebben gekozen. Waar het jouw volgens mij vooral om te doen is dat er tal van leveranciers zijn die onder het mom van Open Source Software onder de motorkap gewoon Closed Source Software aan de man proberen te brengen. Wellicht iets in de trend van "Open Source Software of niet!?".
Nog een andere suggestie: Hou het op Open Source Software (eventueel afgekort tot OSS). Als je het over Open Source hebt zou je dat kunnen afkorten als OS. Dezelde afkorting als voor Open Standaarden. En dat is toch echt heel iets anders.

[Milo van der Linden]

@Simon; dank je wel! Een hele zinnige bijdrage. Zoals mij al vroeg werd geleerd "C'est le ton qui fait la musique"

Inderdaad, primair wil ik waarschuwen voor Open Source Software onder de motorkap maar niet direct in het voordeel van de opdrachtgever. Ik wil hier echter niet keihard op de Closed Source leveranciers in slaan, maar de vragende partij proberen te trainen duurzaam met Open Source projecten om te gaan omdat met name een langdurige toekomst een voordeel levert voor alle kanten van de medaille terwijl "gevechten" met closed source leveranciers in mijn optiek alleen verliezers opleveren.