10 ting at have tjek på inden du vælger open source

Der er store forskelle på kvalitet, udviklingsmodel og support i udbuddet af open source-software. Her er de 10 spørgsmål, som kan evaluere dit valg af open source.

Open source er et attraktivt valg i økonomisk svære tider, men der er faldgruber, som man skal være opmærksom på, før man kaster sin og virksomhedens kærlighed på et bestemt produkt eller kodebibliotek.

Det mener teknologichef Chamindra de Silva fra firmaet Virtusa, som står bag open source-projektet Sahana, der benyttes til katastrofehåndtering.

På bloggen Techrepublic giver han ti bud på forhold, som man skal være opmærksom på, når man vælger open source.

1. Er licensbetingelserne forenelige med forretningens krav?

Open source-software findes under en række licenser, der alle må overholde i hvert fald fire krav: At man frit kan bruge, studere, videregive og forbedre softwaren.

Men derudover kan forskellige licenser stille yderlige krav. For eksempel kræver den ofte anvendte GPL-licens, at forbedringer i koden skal stilles til rådighed for andre. Det er ikke nødvendigvis et problem for en virksomhed, som benytter softwaren internt, mens det kan blive en stopklods for firmaer, der producerer "lukkede" produkter.

2. Er udviklermiljøet stærkt nok?

Open source-udviklere kan være store, forkromede firmaer og organisationer som Mozilla og Sun, men det kan også være en enkelt begavet teenager, som står bag. Et stort og aktivt udviklermiljø omkring et stykke open source-software er et godt tegn på levedygtighed.

3. Hvor mange anvender softwaren?

Modne open source-produkter vil typisk have mange "kunder" i folden. Den bedste information om et produkts anvendelighed vil man som regel få fra en anden bruger i samme branche. Modne produkter vil ofte have en stor, aktiv mailingliste, kun for brugere.

4. Kan man få en garanti eller en kommerciel licens?
Lige ud af papkassen kommer open source-produkter uden nogen garanti overhovedet. Det vil ofte være muligt at få hjælp i brugermiljøet, men visse virksomheder vil ønske at have et garanteret supportforhold. Store, modne produkter vil typisk kunne byde på firmaer, som mod betaling kan yde support i forbindelse med produktet.

5. Er kodekvaliteten i orden?

Afhængig af, hvordan et produkt anvendes, kan det være vigtigt at sikre, at kvaliteten er i orden, og at der bliver fulgt op på nye versioner. Hvis man er i tvivl, kan man enten selv se koden efter, eller lægge det i hænderne på et firma, som specialiserer sig i kvalitetskontrol.

6. Er dokumentationen i orden?

Nogle open source-projekter er ikke gode til dokumentation, da udviklerne oftest er fokuseret på kode og funktionalitet i produktet. Som minimum har man brug for brugermanualer og vejledninger for administratorer. Man skal altid sikre sig, at dokumentationen er fyldestgørende i forhold til behovet hos dem, der skal anvende produktet.

7. Hvor nemt kan produktet tilrettes virksomhedens behov?

I modsætning til lukket software, kan open source tilrettes lige så meget, som man orker. Men udgifterne til tilretning afhænger af produktets arkitektur og de muligheder, som det giver for at udvides, samt kvaliteten af koden og dokumentationen af dets API'er. Gode open source-produkter indeholder en plugin-arkitektur, og ofte vil en leverandør kunne udføre tilretningen mod betaling. Men det er vigtigt, at der er flere muligheder til rådighed. Ellers vil man være lige så låst fast til et enkelt produkt, som hvis man anvender lukket software.

8. Hvorledes styres udviklingen, og hvordan kan retningen påvirkes?

Der er forskellige modeller for, hvordan open source-projekter styres. Den bedste tager alle med, som har en rolle i projektet - udviklere, brugere og leverandører. For større projekter er det vigtigt med en dedikeret organisation, som blandt andet kan håndtere ejendomsretten i projektet. Jo bedre man som aftager af produktet kan engagere udviklermiljøet, jo større mulighed har man for at få indflydelse.

9. Kan produktet skaleres til virksomhedens behov?

Dette krav er lige så vigtigt med open source som med kommerciel, lukket software. Performance-test og case-studier kan være med til at sikre, at softwaren lever op til kravene. Megen open source software bygger på server-stakke så som LAMP og J2EE, som skalerer godt. En ren open source-løsning kan sikre fleksibilitet i det lange løb.

10. Kommer der opdateringer med jævne mellemrum?

Et projekt, som tager sikkerhedshuller alvorligt og kommer med fejlrettelser før hackerangrebene starter, vil have en fastlagt proces for at holde styr på sikkerhedshuller og udbedre dem, før faren opstår. Det samme gælder for lukket software, men open source har den fordel, at man har muligheden for selv at finde og udbedre fejlene, slutter Chamindra de Silva.

Se den originale artikel under fanebladet Eksterne links.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Mogensen

Fejlagtige generaliseringer skaber myter:

For eksempel kræver den ofte anvendte GPL-licens, at forbedringer i koden skal stilles til rådighed for andre.

Nej, det gør den ikke - kun ved videredistribution.
Jeg er godt klar over at sætningen efter det citerede antyder at der er mere i det, men den retter ikke fejlen.

Iøvrigt, så er det jo naivt at tro at blot fordi man har bedre muligheder end hvis man baserede sig på lukket kode, så må man pludselig alt.

  • 0
  • 0
Thomas Ammitzbøll-Bach

GPL handler kun om ændringer i selve programkoden. Det vil sige, at applikeringen, scripts, artwork, branding og andet, der skaber forretningsværdi, er ikke omfattet af publiceringsklausulen. Hvis jeg laver et komplekst produkt med en masse GPL-software i, og jeg har lavet nogle tilføjelser her og der, så er det kun den konkrete programkode, der skal offentliggøres, ikke hele systemet.

Mere generelt: Det er især punkterne 3, 5, 6, 7 og 10, der er vigtige. Et projekt, der ikke er et levende miljø omkring, er farligt at gøre sig afhængig af. Faktisk er det let at købe support, hvis der er en sky af dygtige folk i community'et. Resten kommer af sig selv.

Thomas

  • 0
  • 0
Martin Schlander

Hvor mange af de punkter er lige specifikke for fri software? Stort set samtlige punkter bør også gælde i mere eller mindre uændret form ved anskaffelse af proprietær software.

Der er en tendens til at få fri software til at fremstå frygteligt kompliceret og farligt, men fakta er at du altid pr. definition har langt flere muligheder end du har med proprietær software. Og så længe softwaren kun er til intern brug er der ingen begrænsninger overhovedet - det er først i det øjeblik at der er tale om at videredistribuere ændret software at der kan blive behov for at lidt ekstra omtanke, men det er vel ikke det de fleste forbinder med "brug" af software - alene af den årsag at videredistribuering af ændrede versioner af proprietær software er næsten utænkeligt.

I øvrigt tror jeg ikke der findes en eneste organisation over 4-5 personer i landet, som ikke allerede benytter fri software i et eller andet omfang - dog måske uden at være opmærksom på det.

  • 0
  • 0
Carsten Pedersen

Med mulig undtagelse af punkt 5, er samtlige disse ting noget, en seriøs køber/bruger af et stykke software skal have med i betragtning - open source eller ej.

Artiklens indledning med fokus udelukkende på det økonomiske incitament er også underlig. Der er rigtig mange andre gode grunde til at vælge Open Source.

  • 0
  • 0
Anonym

GPL handler kun om ændringer i selve programkoden. Det vil sige, at applikeringen, scripts, artwork, branding og andet, der skaber forretningsværdi, er ikke omfattet af publiceringsklausulen.

Den almene opfattelse af GPL i de grupper jeg frekventerer er, at hvis du så meget som bruger et komma, skal man eksponere [b]hele[/b] appliaktionen.

Ovenikøbet hvis man laver en statisk linking til et GPL library.

Derfor bliver GPL kaldt 'the viral license', og bliver ikke brugt i Commercial strength software.

Der er nok også en årsag til at QT har ændret fra GPL til LPGL, for ellers er der nok ingen, der gider bruge det.

At tænke sig man skal frigive mange mandeårs arbejde (=investering) som GPL, blot fordi man har brug for en enkelt 'prut' er jo absurd.

  • 0
  • 0
Thomas Ammitzbøll-Bach

Den almene opfattelse af GPL i de grupper jeg frekventerer er, at hvis du så meget som bruger et komma, skal man eksponere hele appliaktionen.

Det er forkert. Det er modifikationer i det oprindelige kildemateriale, som skal publiceres. Linksys har brugt Linux (og andet) i deres wireless routers. De ændringer, de laver i kernen (og andet GPL software) har de offentliggjort, som de skal. Resten (weblogik, eget software, firmware og boot scripts) er ikke omfattet.

Ovenikøbet hvis man laver en statisk linking til et GPL library

Det er derfor de fleste libraries er gjort tilgængelig under LGPL, hvor man gerne må linke til det.

Derfor bliver GPL kaldt 'the viral license', og bliver ikke brugt i Commercial strength software.

GPL software bliver brugt i flere kommercielle produkter end du har spist ærter. Men det er rigtigt, at der eksisterer de ovennævnte myter, og det gør det ofte vanskeligt for udviklere at forklare problemstillingen for en chef, som kun har handelseksamen.

Det er derfor vigtigt, at vi nu sammen gør en indsats for at stoppe denne mytedannelse, og jeg er derfor glad for, at du gør os opmærksomme på de nævnte misforståelser.

Thomas

  • 0
  • 0
Anders Sørensen

hvis applicationen er skrevet i GPL skal ændringerne frigives. Det var et tidspunkt at det var moderne at skrive ekstra kode til GPL softwaren, som tilbød et API sæt (eller lign.,) eller et slags plugin system, til at "omgå" GPL. Så frigav man koden til disse ændringerne, så skrev man ændringerne til api eller som et plugin, som så havde en anden licens (som ikke behøvede at være GPL).

li' en anden ting, hvorfor kan man gå fra GPL til LGPL? jeg ved andre har gjort det, men hvordan? LGPL er ikke et subset af GPL.

og dem som siger at artiklen også gælder lukket kode. Ja, tror artiklen er ment for at vise hva' der bliver set på fra virksomhederne. Hvad der skal "overholdes" før virksomhederne vælger open source.

  • 0
  • 0
Anders Norgaard

At tænke sig man skal frigive mange mandeårs arbejde (=investering) som GPL, blot fordi man har brug for en enkelt 'prut' er jo absurd.

Det er en mærkelig omvendt tankegang du har. Hvis du ikke vil frigive mange års bla bla bla, så skal du jo bare holde fingrene fra GPL kode. Lige som du på alle andre måder skal holde dig fra at sætte dit projekt på spil ved at bryde licensbetingelser.

PS "Commercial strength software" - hvad er det? Windows ME?

  • 0
  • 0
Thomas Ammitzbøll-Bach

[quote]
At tænke sig man skal frigive mange mandeårs arbejde (=investering) som GPL, blot fordi man har brug for en enkelt 'prut' er jo absurd.

Det er en mærkelig omvendt tankegang du har. Hvis du ikke vil frigive mange års bla bla bla, så skal du jo bare holde fingrene fra GPL kode.
[/quote]

Nu tror jeg, at I begge skal klappe hesten! Enhver ejer ophavsretten til sit eget værk uanset licenser. Ingen kan blive tvunget til at distribuere noget, man selv har lavet (med mindre man har solgt distributionsretten).

Hvis en situation opstår, hvor den ene part har brugt den anden parts ophavsretslige materiale på en måde, som ikke er aftalt, så skal den første part: 1) ophøre med det, 2) betale royalties til den anden part.

GPL siger, at hvis licensbetingelserne ikke overholdes, så bortfalder retten til at bruge det materiale, som er omfattet af GPL. Dermed opstår en krænkelse af ophavsretten til materialet, og konsekvensen heraf afklares ved en civil retssag. Sådan er det. En måde at undgå retssag på, kunne være at frigive sit eget materiale under GPL, men det bestemmer man som sagt selv.

Nu kan jeg ikke præcist sige, hvori en 'prut' består, men hvis der er tale om en isoleret funktionalitet, så vil man sikkert betale royalty og derefter udvikle funktionaliteten selv. GPL er ikke en blodspagt, hvor man sælger sin førstefødte.

Men hvem siger, at det er tilfældet? Mere sandsynligt er det, at man har 'glemt' at frigive nogle ændringer i en utility, som er omfattet af GPL; og der går næppe skår af ens samlede system, fordi disse modifikationer bliver frigivet. Faktisk kan det blive en fordel, hvis andre finder svagheder i tilføjelsen og retter det, eller andre bidrager med noget andet.

Jeg har lavet mange kommercielle projekter bygget med GPL-software, og jeg har aldrig oplevet, at projektets kommercielle værdi stod og faldt med en forbedring af en eller anden part. Det meste af den kommercielle værdi lå i "alt det andet": Modellen, systemdesign, scripts, websider, kontroller, dokumentation og drift/overdragelse.

Thomas

  • 0
  • 0
Claus Stovgaard

Der er ikke kun Open Source specifik. Alle de nævnte krav er jo noget der skal tages stilling til, ligegyldig om man benytter Open Source, eller køber et produkt.

Valg af licens betingelser skal altid passe til projektet. F.eks. så kan et embedded system være et mareridt med licenser. Valg af OS f.eks. DSP/BIOS, QNX, eCos, Linux og valg af tilhørende moduler kan alle være underlagt forskellige licenser. Også med hensyn til royalties osv. hvilket jo kan gøre det til et juridisk mareridt.

GPL har fordele og ulemper. Den er stor og kompleks sammenlignet med BSD og MIT licensen. Der er en gråzone med dynamisk linkning af programmer. FSF mener jo at hvis de deler datastrukture er det underlagt GPL kravet. Fordelen med GPL er at den har "tvunget" nogen til at frigive kode der ellers ikke vil være frigivet. Bemærk ", da jeg selvfølgelig ikke kan spå.

Personligt bryder jeg mig ikke om GPL til embedded enheder da den netop kræver at hvis jeg ønsker at vider distribuere enheden, og det er statisk linket sammen, skal det hele være underlagt GPL. De begrænser optræder jo ikke når man benytter f.eks. BSD licenseret kode.

Selv benytter jeg generelt BSD licensen for mine projekter, da det giver gode muligheder for at de kan bruges i alle projekter. Også til ting som ikke nødvendigvis er Open Source.

  • 0
  • 0
Lars Lundin

Det er især punkterne 3, 5, 6, 7 og 10, der er vigtige.

Punkt 2 mener jeg også er vigtigt.

GPL programmet f-spot har for eksempel et stort antal brugere (fordi det er en del af Ubuntu).

Men programmets oprindelige forfatter døde (i en alt for ung alder) kun 5 uger efter at have publiceret første version af det.

F-spot har i flere år haft seriøse mangler, som den nuværende udvikler (eller måske rettere vedligeholder) ikke får gjort noget ved. Og uden at man kan beskylde nogen med forbindelse til f-spot-projektet for noget som helst, så skal man nok lige tænkte sig om inden man investerer tid i sådan et projekt.

Et andet eksempel er splint, som for nogle år siden virkede temmelig godt, men som herefter nærmest er gået i stå.

  • 0
  • 0
Log ind eller Opret konto for at kommentere