Open Source for kritiske løsninger og bedrifter med høye krav

Professional Open Source er et uttrykk vi bruker i Conduct for å beskrive Open Source-produkter som omgis av et sett tjenester som dekker forretningskritiske behov. Dette betyr at kjerneproduktet (f.eks. mellomvare, en database eller web-tjener) har et etablert selskap i ryggen som tilbyr support og sikrer videreutvikling av produktet med en langsiktig og stabil visjon. Produktene er state-of-the-art og har kvalitet og funksjonalitet som er like god eller bedre enn sine kommersielle/proprietære konkurrenter, og selskapene tilbyr SLA (Service Level Agreements) som kreves av forretningskritiske systemer. Eksempel på andre Professional Open Source selskaper er f.eks. Red Hat, Pentaho og Alfresco.

Conduct sin visjon er å være den beste norske leverandøren!

Som et ledende norske Open Source-selskapet sikrer vi at det finnes lokal tilstedeværelse og ekspertise på plattformene vi har valgt ut i vår produktportefølje. Utviklingsbistand, rådgivning og prosjektgjennomføring med utgangspunkt i stabile Open Source-produkter kan bety store besparelser og mer effektive IT-systemer for våre kunder.

Hva er egentlig Open Source?

Nedenfor har vi samlet litt informasjon om Open Source (norsk: Åpen Kildekode/Friprog). Teksten er basert på spørsmål vi har fått fra kundene våre de siste seks årene, og kanskje sitter du med spørsmål som du finner svar på hvis du tar deg tid til å lese gjennom dette.
Har du kommentarer, ytterligere spørsmål eller tilbakemeldinger til oss, så setter vi selvsagt pris på å høre fra deg. Bruk gjerne skjemaet her!

Kort historisk oversikt

Unix

Unix sin historie går tilbake til begynnelsen av 70-tallet, da det ble utviklet av AT&T for PDP-77. Sammen med unix laget de også programmeringsspråket C som unix ble utviklet i. At det ble laget i et språk som var uavhengig av maskinvareplattform var et visjonært steg som gjorde unix til det første utbredte operativsystemet som ble tilgjengelig på annen maskinvare enn det først ble utviklet for.

Utover 80-tallet ble det i det akademiske miljøet ledet av UC California på Berkeley utviklet en variant av Unix kalt BSD (Berkeley Software Distribution). Parallellt videreutviklet AT&T sin unix, men begge varianter endte opp med å inkludere mange av hverandres egenskaper.

BSD endte opp som åpen kildekode, og lever fortsatt i mange varianter (FreeBSD, OpenBSD, NetBSD, også basis i Darwin/MacOSX)

Free Software Foundation

Richard Stallman startet Free Software Foundation (FSF) og GNU-prosjektet (GNU's not unix) i 1985 for å lage en fri versjon av unix. Fri betyr i denne sammenhengen programvare som fritt kan bli brukt, lest, endret og distribuert. Dette er formulert i GPL, General Public Licence. GNU har hatt stor suksess med flere programvarepakker, mest kjent er kompilatoren GCC og redigeringsverktøyet Emacs, men hadde problemer med å få på plass en operativsystem-kjerne som trengs for å ha et fullverdig operativsystem.

Linux

Linux' historie er velkjent. Dette ble startet som et hobby-prosjekt av finnen Linus Torvalds i 1991, men har etter dette blitt videreutviklet til et fullverdig profesjonelt operativsystem. Sammenhengen mellom GNU og Linux er ganske interessant. Som nevnt ovenfor hadde GNU på begynnelsen av 90-tallet ikke noen kjerne. Linux hadde en kjerne, men manglet nødvendige verktøy. Det vi idag kjenner som Linux, er videreutviklingen av Linus' kjerne, kombinert med bibliotek og verktøy fra GNU. Operativsystemet kalles derfor av mange GNU/Linux.

Hva betyr Åpen?

«Åpen» brukt om kildekode betyr flere ting:

  • Man kan videredistribuere programmet
  • Man har tilgang til å lese kildekoden til et program for å kunne lære hvordan det virker
  • Man har anledning til å endre kildekoden til et program for eget bruk
  • Man kan videredistribuere programmet med sine egne endringer
  • Man kan lage nye programmer basert på eller som inkluderer deler av den åpne kildekoden.

All programvare distribueres med en lisens. Denne definerer begrensninger for hvilke rettigheter mottakeren av programvaren har. Open Source Initiative har definert en rekke vilkår som må tilfredsstilles for at en lisens skal kunne anses som open source, og som gir brukeren rettighetene listet ovenfor.

Alternativet til åpen kildekode er proprietær/eiet programvare med lukket kildekode. Som bruker av slik programvare mister man for det første fordelene man kunne hatt ved å ha tilgang til kildekoden. For det andre har ofte lisensene til slik programvare også klausuler som begrenser bruk, ytelsesmålinger, eller gir leverandøren rett til å trekke tilbake lisensen uten forvarsel.

Åpen kildekode idag

Idag ser vi åpen kildekode brukt i mange sammenhenger og det finnes mange anerkjente produkter av høy kvalitet. Kjente eksempler er:

Apache web-server er et både godt og velkjent eksempel. Ikke bare har apache i stor grad definert hva en web-server er de siste 10 årene, men Apache er fortsatt den suverent dominerende markedslederen for web-servere, iflg. Netcraft

Linux er et annet eksempel som er velkjent for de fleste. Det kan være interessant å se linux som en variant av unix i et historisk perspektiv: Unix har vært en anerkjent familie av operativsystemer siden 70-tallet, og har hele tiden hatt et viktig element av åpen kildekode i seg. Vesentlige deler av moderne unix slik vi kjenner det idag er utviklet ved UC Berkeley som BSD og har hele tiden vært åpen og tilgjengelig. BSD er fortsatt i bruk i flere varianter, men har også vært et vesentlig bidrag til mange operativsystemer med lukket kildekode.

Innenfor databaser finnes også mange eksempler på produkter med åpen kildekode, men svenske MySQL er kanskje det med størst suksess. Prinsippene bak relasjonsdatabaser har vært kjent siden 70-tallet. Oracle og IBM som historisk har vært og fortsatt er to av de viktigste databaseleverandørene har levert sine produkter siden begynnelsen av 80-tallet. Første versjon av MySQL ble lansert i 1996. De siste 5 årene har MySQL blitt en reell konkurrent til de gamle proprietære systemene. Her kan vi se et mønster vi også skal undersøke nærmere nedenfor: ny teknologi starter som et proprietært produkt, blir standardisert, flere leverandører kommer på banen, lukkede alternativer blir utkonkurrert av de med åpen kildekode og til slutt er de en standard del av infrastrukturen. Når en teknologi har kommet til dette nivået er marginene så lave at det ikke lenger er mulig å tjene penger på å selge teknologi alene. Dette gjelder ikke bare programvare. For maskinvare er forskjellen mellom leverandørene veldig liten og og det går kort tid fra en ny teknologi er tilgjengelig til den er standardisert og uten å gi noen konkurransefortrinn. Innenfor java-teknologi finnes det stadig flere eksempler på produkter basert på åpen kildekode som ikke bare er gode alternativer innenfor sitt segment, men som også er med å definere videreutviklingen av teknologien.

JBoss er kanskje det mest kjente eksempelet. Fra Sun lanserte J2EE i 1999 til JBoss vokste frem som aktuell plattform i 2000 og det ble et profesjonelt alternativ i 2001 gikk det bare 2 år. Utviklingen som altså tok 20 år for SQL-databaser, gikk på bare 2 år for Java EE (Enterprise Edition). For nyere teknologier går det enda raskere. Portaler slik vi kjenner begrepet fra portlet-standarden JSR-168 oppsto først som funksjonalitet i proprietære applikasjonsservere, men det gikk kort tid før funksjonaliteten ble beskrevet som en standard. Samtidig med dette ble det utviklet referanseimplementasjoner av standarden som er tilgjengelig som åpen kildekode. Eksemplene er mange på denne utviklingen:

Tidsrommet hvor det er mulig å tjene penger på salg av programvare alene, fra en teknologi er ny i et proprietært produkt til det er en standardisert del av infrastrukturen blir stadig kortere.

Hvorfor er åpen kildekode viktig

Som kunde er det flere viktige spørsmål man må stille når man skal gjøre en investering. Hvor lenge vil systemet leve? Hva blir vedlikeholdskostnadene? Hvilke muligheter vil åpne seg? Hvilke vil lukkes? Hvordan vil behovene endres over tid? Hvordan kan systemet tilpasses endrede behov?

Programvare med åpen kildekode har flere gode egenskaper sett i lys av disse spørsmålene:

  • Standardisering Det kanskje viktigste poenget for å sørge for langsiktighet er å basere systemutvikling på anerkjente standarder som støttes av flere leverandører. Dette vil sikre at systemer kan leve videre uavhengig av plattformleverandør, større tilgjengelighet på kompetanse (det er flere som kan for eksempel J2EE enn de som kan ett konkret J2EE produkt). Fri programvare har ikke et stort salgsapparat som selger for seg. Derimot finnes det en grunnleggende holdning om at standarder er viktig, som reflekteres i produktene. Vi har sett flere eksempler på dette ovenfor, hvor produkter med åpen kildekode blir valgt som referanseimplementasjoner for standarder, og i stor grad er med å drive standardiseringsarbeid videre.
  • Integrasjonsmuligheter Et produkt med åpen kildekode vil være enklere å integrere enn et som er fullstendig lukket. Dette ser man flere eksempler på. JBoss består av en mengde mindre moduler som alle er tett integrert i samme arkitektur. Dette er delsystemer som har blitt utviklet utenfor JBoss-prosjektet, som så senere har blitt inkludert, og som hele tiden har vært tett integrert. Vi ser altså både innenfor JBoss-prosjektet og utenfor at nye produkter integreres mot JBoss. Dette gir mange muligheter både idag og for fremtidige utvidelser og endringer, men lukker ingen dører.
  • Ingen lisenskostnader Lisensmodellene for åpen kildekode gir som kjent mange rettigheter til brukerne av et produkt, både når det gjelder bruk og videreutvikling. Konsekvensen av dette er en helt annen forretningsmodell for programvare, hvor man ikke lenger tar betalt høye lisenskostnader for å distribuere en installasjons-CD. Dette vil gi mer penger til implementering og videreutvikling, som igjen innebærer høyere kvalitet for sluttbrukere.

Fra et utvikler-perspektiv er det også store fordeler ved åpen kildekode, noe enhver utviklingssjef bør tenke på:

  • Kraftige verktøy Fri programvare basert på åpen kildekode blir veldig ofte startet for å dekke et teknisk behov, ikke et markedsbehov. Dette gjør at de har en arkitektur som utviklere trives med, kraftige verktøy som gjør en istand til å arbeide mer effektivt og integrasjonsmuligheter som gir stor fleksibilitet. Dette er momenter som gjør åpen kildekode mer morsomme å jobbe med enn proprietære systemer. Mer morsom teknologi betyr mer motiverte medarbeidere og økt effektivitet.
  • Kildekode tilgjengelig Om dokumentasjonen er aldri så god, kommer man av og til i situasjoner hvor man opplever feilsituasjoner som ikke er dekket av dokumentasjonen, eller ønsker å løse et problem som ikke ligner på noen av eksemplene, eller trenger å skyve systemet enda lenger i en retning enn det har vært gjort før. Da er det en klar fordel å ha kildekoden tilgjengelig. Det finnes ingen hemmeligheter man ikke kan finne frem til, og det er ingen grenser for hvor dypt feilsøkingen kan stikke, om man har behov for det.

Her skal man også legge merke til fremveksten av internett som en viktig drifkraft for åpen kildekode. Internett gjør oss istand til å bygge nettverk av brukere, leverandører og bidragsytere uavhengig av geografi og programvare og kunnskap kan flyttes med liten eller ingen kostnad. Dette gjør videre at slike nettverk blir større og billigere, utvikling av programvare går raskere og gevinsten ved å ha åpen og tilgjengelig kildekode blir større.

Motforestillinger

Noen vanlige antagelser om åpen kildekode:

Man kan ikke selge programvare bygget på åpen kildekode

Dette er ikke riktig. De ulike lisensene for åpen programvare definerer vilkår for distribusjon av programvaren, men ingen av de nekter deg å ta penger for distribusjonen.

Det er umulig å tjene penger på åpen kildekode

Dette er beviselig feil, det er mange som tjener penger på åpen kildekode. Riktignok er det ikke mange som tjener penger på å selge programvaren i seg selv, men man har andre forretningsmodeller hvor man tjener penger på vedlikehold, brukerstøtte, rådgiving og tilpasninger.

Om vi benytter programvare med åpen kildekode må vi offentliggjøre all kildekoden vår.

Dette er ikke riktig. For noen lisensmodeller (spesifikt gjelder dette GPL, General Public Licence) kreves det at dersom du distribuerer et program bygget på GPL må kildekoden legges ved. Dette vil si for eksempel at dersom man lager et program som skal distribueres, må du tilgjengeliggjøre kildekoden. Dersom man lager et program som ikke distribueres (for eksempel at det tilbyr en tjeneste over internett, men programvaren i seg selv kjører på egne servere), trenger man heller ikke distribuere kildekoden. Mer om lisensmodeller nedenfor.

Konklusjoner

Ovenfor har vi vist at:

  • Åpen kildekode gir brukeren muligheter og rettigheter som er utenkelig med lukket kildekode og proprietær programvare.
  • Systemer bygget på åpen kildekode har ofte en arkitektur og verktøy som utviklere trives med og som gir økt effektivitet.
  • For fri programvare med åpen kildekode er det ekstra viktig å følge standarder, dette gjør det enklere som kunde å være leverandøruavhengig.
  • Programvare uten lisenskostnader gir mer penger til implementering av systemet

Oversikt over vanlige lisenser for åpen kildekode

Navn Rettigheter og begrensninger i lisensen Brukes f.eks. av
GPL (General Public Licence) Rett til å gjøre endringer i kildekode, rett til å distribuere programmet med eller uten endringer, rett til å bruke deler av kildekoden i et nytt system. Forutsetter at all distribusjon av programmet enten i original versjon eller modifisert også følger GPL. Forutsetter også at om et distribuert system inkluderer kode under GPL eller er linket med delsystemer under GPL, må systemet som helhet også være under GPL. Dette innebærer at om man bruker GPL-kode i et system, «smitter» GPL over på hele systemet. Dette betyr ikke at man må distribuere systemet til hele verden, men at dersom man distribuerer det, må mottakeren få de samme rettigheter til å modifisere og distribuere. Linux-kjernen, GCC, Emacs, Readline
LGPL (Lesser General Public Licence) Dette er i utgangspunktet det samme som GPL, men hvis man linker med et LGPL-bibliotek kreves det ikke at hele systemet får samme lisens. Dette betyr i praksis at man kan inkluderer biblioteker med LGPL-lisens, mens ens egen kode er lukket. Derfor er denne lisensen mer Business Friendly enn GPL. GNU C-bibliotek, JBoss
Apache (APL) Innebærer kort fortalt at man kan gjøre hva man vil med kildekoden, så lenge det fremgår at systemet er basert på kode under Apache-lisens. Apache-lisensen har også en klausul om patenter. Alle apachebibliotek, web-server, tomcat, apache-commons
BSD (Berkley Software Development) Sier kort fortalt at man kan gjøre hva man vil med koden, men all distribusjon av kildekode eller binærfiler må følges av original copyright og lisens Alle BSD-varianter (operativsystem), PostgreSQL

Referanser