Zonder opensource-code zou de wereld zoals we die vandaag kennen, piepend tot halt komen. Ook bedrijfssoftware staat er vol van. Terecht: niemand heeft er iets aan wanneer jij de tijd investeert om het warmwater opnieuw uit te vinden. Toch komt opensource-code niet zonder risico’s.

1. Amateurs of professionals?

Het eerste grote vraagteken is de kwaliteit van de code. In de regel heeft opensource een goede naam. Aan grote projecten werken professionele ontwikkelaars van over de hele wereld mee. Updates met slordige code worden opgeschoond en best practices gevolgd. Niet ieder project heeft echter evenveel volgers als de Linux-kernel. Zeker bij kleinere stukjes opensource-code moet je oppassen. Een nuttig stukje code kan gebouwd zijn door tien professionals maar ook door een éénzame eerstejaarsstudent met veel ambitie maar weinig talent.

Enkele vuistregels helpen je verder. Kijk bijvoorbeeld eens naar de kwaliteit van de bijhorende documentatie en de hoeveelheid commits. Verder kunnen online tools je op weg helpen, of kan je zelf een steekproef uitvoeren. De eerste stap is om je ervan bewust te zijn dat een handig project niet noodzakelijk een kwalitatief project is.

2. Ondersteuning

Aansluitend moet je de ondersteuning in het achterhoofd houden. Grote en populaire projecten vinden hun vrijwilligers om ze in leven te houden, maar wat met die kleinere of meer gerichtere stukjes code. Het passieproject van één Java-goeroe ergens in de bergen van Nebraska kan twintig jaar lang dienst bewijzen, tot de oprichter op welverdiend pensioen gaat en de wereld van 0 en 1 vaarwel zegt. Plots stagneert het project, terwijl de code wel een essentieel onderdeel uitmaakt van de bedrijfstoepassing die je ontwikkelde.

Daarom is het een goed idee om na te gaan hoe groot het enthousiasme rond een bepaald component is. Zie je een halfjaarlijkse commit door dezelfde expert? Of zijn collega’s wereldwijd er wekelijks of dagelijks mee bezig? Als een op sterven na dood project écht handig is, kan je natuurlijk stiefvader- of moederschap overwegen. De opensource-gemeenschap geeft, zolang mensen bereid zijn om terug te geven.

3. Wat mag je ermee doen?

Het is niet omdat je wegblijft van grote ondernemingen, dat licenties plots verleden tijd zijn. Ook opensource-code is onderhevig aan licenties. Voor persoonlijke projecten hoef je daar niet zo van wakker te liggen, wanneer je code integreert in een bedrijfstoepassing denk je best wel twee keer na.

Opensource-licenties bestaan in honderden smaakjes. Sommige licenties laten alles toe. In dat geval kan je de code van een component zonder vrees aanpassen en gebruiken in de toepassing die je bouwt, ongeacht of ze voor intern dan wel extern gebruik is.

Anders is het bij zogenaamde copyleft-licenties. Code die onderhevig is aan een dergelijke licentie mag je nog steeds gebruiken in een eigen softwareproduct, maar je wordt verwacht de aanpassingen opnieuw te delen met de opensource-gemeenschap wanneer je de afgewerkte software met de wereld deelt. Bouw je een commerciële bedrijfstoepassing met een opensource-component, dan kan die voorwaarde problematisch zijn.

En wat met het veelvoud aan code zonder aangeduide licentie? Ook die is onderhevig aan copyright-wetgeving. Het gebruik ervan in commerciële producten brengt risico’s met zich mee. Let dus goed op voor je een stukje code in een bedrijfstoepassing integreert.

4. Veilig maar niet onfeilbaar

Tot slot denk je best even na over de beveiligingsrepercussies wanneer je opensource-code integreert in een toepassing. Omdat iedereen opensource-code kan nakijken is er doorgaans veel veiliger dan alternatieven ontwikkeld tussen bedrijfsmuren. 500 paar ogen zien veel meer dan vijf paar en in security through obscurity gelooft intussen niemand meer.

Zelfs honderden mensen kunnen af en toe de bal misslaan. Kijk maar naar de populaire opensource-loggingtool Log4j. Die zit geïntegreerd in tienduizenden toepassingen over de hele wereld, van eigen bedrijfsapplicaties van een kmo tot software van giganten zoals VMware. Log4j bleek pas een kritieke fout te bevatten en dat heeft grote gevolgen. Iedereen die het opensource-component heeft geïntegreerd in een toepassing, moet nu een update voorzien voor die toepassing.

Dat gaat, zolang je goed weet welke opensource-componenten je gebruikte in eigen projecten en in het oog houdt of ze geen kwetsbaarheden vertonen. Hou dus goed bij welke componenten je waar integreerde, en volg hun status geregeld op.

5. Beheer

Uiteindelijk is er één gouden regel: weet wat je gebruikt en waar. Wie goed in het oog houdt welke opensource-componenten in welke bedrijfstoepassingen zitten, en ook de evolutie van de opensource-code zelf opvolgt, zal niet snel in de problemen komen. Zolang je niet vergeet dat gratis niet hetzelfde betekent als licentievrij.