Valg av open source-biblioteker

Analyser gjort av blant annet SSB (Statistisk sentralbyrå) viser at over 50 prosent av alle norske programvareprodusenter nå bruker frie OSS-komponenter i sine systemløsninger. Stadig større del av dette er OSS-biblioteker. Vi har oppsummert opp hva du bør tenke på når du velge.

Nets har bygget opp intern kompetanse på Java, IDE (Integrated Development Environment) utviklingsverktøy, Subversion som versjonskontroll, Maven byggverktøy, Hudson som byggserver og testmiljø basert på JUnit og Fitnesse. I tillegg er kompetansen høy på generelle GNU utviklingsverktøy. Utviklingsprosjektene velger selv de åpne-kildekode-biblioteker som de har behov for.

Siden vi bruker Maven som byggverktøy kan enhver utvikler fritt velge IDE. Maven sørger for at korrekte versjoner av tredjepartsbiblioteker benyttes, bygger, pakker og distribuerer programvaren.

Bruk av OSS-komponenter i forretningskode

I dag finnes det over 200.000 tilgjengelige gjenbrukbare OSS-komponenter i Java (en god del av disse er klassebiblioteker) (http://www.idi.ntnu.no/emner/tdt10/curricula/P1-7-conradi09.pdf). Alle større nye Java-prosjekter er man avhengige av åpen kildekode. Den største bidragsyteren her er åpne kildekodebiblioteker.

Et viktig kriterium for valg av åpne kildekodekomponenter eller programmer, er at produktet utvikles aktivt. Dette kan man ofte utlede av tilstanden på produktets hjemmeside. Før vi velger OSS-kode sjekker vi om produktet har en aktiv base av brukere. Er det et aktivt miljø rundt produktet? Er produktet støttet av et selskap? Det er også viktig å avklare om produktet er støttet av OSS-organisasjoner som for eksempel Apache eller av et programvarehus.

Man bør kun velge produkter som har et minimum av aktivitet. Når man skal vurdere nye åpne kildekode-produkt/biblioteket har man alltid risikoen for at miljøet bak produktet vil forsvinne, og dermed forsvinner også muligheten for at andre tar ansvar for bugfixer og utvikling av nye funksjoner. Mange prosjekter i dag støttes av store selskaper. Andre prosjekter vurderes som så populære og med så stor bruker- og utviklerbase at risikoen anses som liten. Når du velger mindre prosjekter uten selskapsstøtte eller stor brukerbase er risikoen stor for at man må fikse feil og legge til nye funksjoner selv.

Hvilken lisensmodell kan du velge?

Når punktene over er tilfredsstilt står vi igjen med lisensmodellen. Lisensmodeller som har spesifikke gjensidige bindinger brukes vanligvis ikke av større programvarehus.

Mindre produkter med APL (APL=Adaptive Public License, en Open Source lisens fra Universitet i Victoria), MIT (MIT License er en gratis software-lisens som kommer fra Massachusetts Institute of Technology), og BSD-lisenser kan brukes av de enkelte prosjektene etter skjønn. Stort sett det meste av programvare som følger disse lisensene krever ingen juridisk vurdering fra de enkelte programvarehuset som skal benytte disse, eksempler på populær programvare som bruker disse lisensmodeller er Spring-rammeverket og Apache webserver.

Når det gjelder produkter som støtter GPL og LGPL brukes i disse stort sett i serverløsninger (Linux-kernel, Linux/Unix-serverprosesser, operativsystem- ognettverkssystem-programmer) og ikke i Nets-kildekode siden disse lisensene ikke krever gjensidighet. De fleste løsningene basert på GPL og LGPL bør det kjøres en formell evaluering før dette brukes i egen kode.

En enkel sjekkliste

Ønsker du å lage ditt et eget rammeverk med tilhørende retningslinjer i forbindelse bruk av OSS-biblioteker kan det være nyttig å lese den vitensskaplige artikkelen fra University of Iowa (http://ir.uiowa.edu/cgi/viewcontent.cgi?article=1021&context=bsides&sei-redir=1#search=%22open+source+libraries+in+business+applications%22) «Open Source Software Libraries».

Under har jeg listet opp en enkel sjekkliste:

• Valgt OSS-bibliotek har et aktivt nettsted med (tilhørende support, patch-regime etc)
• Vi forutsetter at valgt OSS-bibliotek har en tilfredsstillende kvalitet for deg og din bedrift med hensyn til dokumentasjon, bibliotek som f.eks. ingen deadlock (http://people.csail.mit.edu/amy/papers/deadlock-ecoop05.pdf) med låsing av tråder.
• En enkelt pakke kan inneholde kode under forskjellige lisenser. Sjekk alle lisensvariantene.
• Hva innebærer lisensen for deg og din organisasjon?
• Unngå all programvare som har tvetydige, uklare, eller kompliserte lisenser.
• Skal du eller din bedrift utgi programvare under en fri / åpen lisens, bruk en av de kjente og etablerte lisensene – ikke lag din egen lisens.

I vår anskaffelsesprosess i forbindelse med å ta i bruk OSS-biblioteker, står det at all programkode skal gjennomleses, og at større etablerte mye brukte biblioteker kan godkjennes uten gjennomlesing.

Når det velges eksterne OSS-klassebiblioteker ser vi at det i mange tilfeller blir bedre kodekvalitet. I tillegg reduserer dette også mengden av spesiell kunnskap og nødvendig intern-dokumentasjon.

Produksjonsmiljøene våre har valgt Linux-operativsystemet som med tradisjonelle server-prosesser som samba, nfs, smtp, sendmail og så videre. Disse løsningene er underlagt GPL-lisensmodellen. Nets har også OSS-produkter som er plassert høyere opp i næringskjeden som for eksempel osCommerce-løsningen (http://www.oscommerce.com/). osCommerce er en nettbutikk/e-handelsløsning som er gratis tilgjengelig under GNU General Public License. osCommerce gjør det enkelt å sette opp, drifte og vedlikeholde nettbutikker. Vi har integrert løsningen til vårt eget system Netaxept. osCommerce er et eksempel på et komplett, åpent kildekodeprogram som dekker et forretningsmessig behov og er ikke bare et Java bibliotek eller verktøy.

Takk: En takk til Truls Thirud og Bjørn Nordlund og for faglig bidrag.

Ukens kommentator: David Elboth, hovedarkitekt for IT Operation i Nets, les bloggen her.

Kilder:

Verdikt, NTNU, 16. mars 2009, v2.1

B Sides

Static Deadlock Detection for Java Libraries