Den modne open source løsning

Jeg var ude hos en kunde i denne uge, for at holde foredrag omkring infrastruktursikkerhed. I min præsentation anbefalede jeg at indsamle og behandle data med en hel masse open source produkter.

En kommentar handlede så om open source modenhed, sådan opsummeret.

Kan vi bruge open source? Hvordan med de værktøjer jeg anbefaler, findes de overhovedet imorgen?

Mit postulat er jo at man med diverse projekter fra Github kan finde noget som løser XX % af en given opgave, og derved er der 100-XX % tilbage som man selv skal igang med. Faktisk vil jeg mene at vi i mange tilfælde kan finde noget som løser det umiddelbare problem "godt nok", og derved løse opgaven nu og her.

Samtidig kan vi se en strategi for selv at videreudvikle løsningen til fremtiden, eller betale andre for at videreudvikle de manglende dele.

Selv elsker jeg Github, og har sat "stjerne" ved 400 projekter, som nok desværre er en indikation af at jeg sætter stjerne når jeg synes det lyder spændende, men ikke altid når at evaluere disse mange projekter - og fjerne stjernen igen for irrelevante projekter.

Tidligere havde jeg visse indikationer på om et stykke open source var modent:

  • Det lå hos Apache Foundation og var angivet som værende i inkubator hos dem
  • Der er mindst een O'Reilly bog om emnet/softwaren
  • Der var aktive mailinglister med folk som var glade og hjalp hinanden

Idag har vi også mulighed for at vurdere ved at se på:

  • hvornår er det oprettet
  • hvad er seneste release
  • hvordan med bugs - mange er sådan set fint, hvis de rettes løbende
  • hvem er med i projektet

På Github er det særligt nemt at se status, fordi det er ens for alle projekter der ligger der. Vi kan yderligere se hvad personerne bagved ellers laver.

Se blot https://github.com/Exa-Networks/exabgp

Anbefalede værktøjer

Jeg har således flere gode open source projekter som jeg anbefaler:

Versionsnummer lige efter navnet er dags dato, og man ser et mønster. Der er ikke noget 0.0.01-alpha-may-work-on-my-laptop

Så jeg leder altså efter værktøjer som er åbne, fordi det er nemt at integrere med andre og jeg kan give det frit ud til kursister, tilhørere og andre - plus selv bruge dem frit i egne miljøer. Dem som overlever at komme forbi version 1.0 og skaber et community ved hjælp af god dokumentation og regelmæssige releases får plus point.

Metrics for Open Source modenhed

Så uden at jeg kan angive en præcis metric for open source modenhed, er her nogle karakteristika som for mig betyder noget.

  • Open Source - jeg kan modificere eller betale andre for at modificere, kan typisk installere instanser efter behov, ikke efter budget til licenser
  • Stabil software, gerne med stable release og bleeding edge versioner
  • Mulighed for opgradering mellem stable releases, lyder måske simpelt men for eksempelvis OpenStack pt. ser det skidt ud! Det diskvalificerer næsten alene et projekt
  • Ref sidste bullet, et stabilt design for arkitekturen er et plus. Det betyder ikke det aldrig ændres, men hvis udviklerne skifter hele undervognen ud mellem hver release, så er der noget galt
  • Faste releases, eller ihvertfald oftere end Debian og Irssi der tidligere var flere år om at komme med ny versioner. Hvis der som OpenBSD kommer release hvert halve år, så kan man nemmere sige til en udvikler, din kode er ikke god nok nu - men om 6 mdr kommer du med i release. Brugerne kan også regne med at de kan opdatere løbende med få problemer.
  • # devs > 1 - der skal minimum være en gruppe bagved, ellers er bus faktoren for stor.
  • Community, der skal gerne være en kritisk masse af brugere, som rent faktisk bruger features og rapporterer tilbage. Jeg har skræmmeeksemplet med OpenStack hvor delkomponenter slet ikke virker når man prøvede at bruge dem
  • Dokumentation er vigtig, og her vil jeg fremhæve OpenBSD mansider og aircrack tutorials som gode eksempler
  • Sprog og platforme, skal gerne matche det jeg allerede bruger - men vil over tid kunne ændre. Eksempelvis ser jeg mere og mere i Go programmeringssproget, og vi bruger således allerede småting i Go. Det er fint, men man skal være opmærksom på det. Vi prøver også at holde os til et mindre antal teknologier vi skal understøtte, så eventuelt gammelt Perl kunne man måske udradere, og så er der "plads" til at tillade Go ind i miljøet
  • Fremtidig strategi og planer for udvikling - er projektet på vej i en retning som giver mening for os. Hvis det kun er open source nu mens det udvikles, men er på vej til kommercielle udgaver hvor alle nødvendige features bliver låst, så er det mindre interessant

Der findes sikkert forsøg på at modelere dette og fortæl gerne hvis du ved mere. Jeg vil dog sige man altid skal vurdere modenheden i forhold til ens miljø og organisationen som skal bruge værktøjet. Googling giver en model som jeg dog ikke kender til, eller mindes at have brugt/set brugt: https://en.wikipedia.org/wiki/OpenSource_Maturity_Model og ligeledes https://en.wikipedia.org/wiki/Open-source_software_assessment_methodologies.

Men hvordan vurderer du selv software som værende "klar til produktion"?

og har du eksempler på værktøjer som simpelthen havde så stor umiddelbar værdi at du brugte det, uanset det var helt nyt?

eller har du skræmmeeksemplet på at I brugte en masse tid på X, hvorefter X bare gik i stå ... Jeg savnede i flere år opdateringer til Dspam (http://nuclearelephant.com/) som var et anti-spam filter som jeg var mægtigt glad for. Det var et super stykke software som kørte godt, men som så blev efterladt i limbo i noget tid.

Nye teknologier tager tid

Så er der også nyere teknologier som jeg har valgt selv at kaste mig over, noget med at spise sin egen hundeæde.

Det er eksempelvis Qubes OS A reasonably secure operating system https://www.qubes-os.org/

Da jeg stødte på det første gang havde jeg svært ved at installere det. Så engang på Thecamp.dk sommerlejr havde jeg en stationær med som kunne installere det, wooohooo YAY! Senere fik jeg fumlet det ind på en laptop, og nu er det installeret på min private laptop Librem 15 som med stor glæde kører version 3.2. Hele processen tog vel samlet over et år fra ønsket om at se mere på det til jeg rent faktisk bruger det.

Der sker altså en modning, som i Qubes tilfælde er gået relativt hurtigt, og med stormskridt i de sidste versioner. Så nogle værktøjer skal man følge i flere år, før man tør bruge dem i praksis.

Ligeledes bliver jeg dygtigere til at bruge Qubes og de muligheder der er. Senest har jeg konfigureret den VM der henter og viser min post til KUN at kunne tilgå min mailserver :-D

Open Source bøgerne

En anden vej at komme til de rigtigt gode open source projekter er også via bøger.

Her tænker jeg specielt på bøger som beskriver baggrund for teknologierne, pragmatiske og praktiske eksempler, samt køreklare opskrifter. Den slags bøger kan hurtigt være $20-50 værd, og som et fantastisk eksempel er bogen nedenfor.

Den er udkommet i 2014 og 2 releases, med en 2nd edition på vej i August 2017. Bogen er lige under 350 sider men formår at introducere værktøjer med forklaring på hvordan de bruges i praksis, og peger på andre resourcer der så kan hjælpe en mere i dybden. Det skaber overblik og kickstarter brugen af værktøjerne.

Network Security Through Data Analysis by Michael Collins 2014-02-05: First release 2015-05-01: Second release http://shop.oreilly.com/product/0636920052470.do

Nej, får ingen penge for at anbefale O'Reilly men de har siden jeg lærte dem at kende i start 1990'erne udgivet mange gode bøger.

Konklusion

Vi har idag taget open source ind i vores organisationer som en naturlig del, heldigvis. Desværre er der stadig en modstand imod det, måske baseret på uheldige oplevelser med enkeltprodukter. Så ligesom med andre stykker software bør vi altid overveje fordele, gevinster og ulemper ved at implementere løsningerne.

Ovenstående er set fra min stol, men hvad gør I andre?

Specielt kunne jeg godt tænke mig at høre ting som, er der organisationer som stadig helt fravælger open source, og med hvad begrundelse.

Soundtrack

PS Der er ikke som sådan et bestemt lydspor, for hvad sange signalerer lige moden software?

Jeg hørte dog en af mine favoritplaylister https://open.spotify.com/user/panpietras/playlist/4B9vHEv4ZJmeMusVp1JVLX som jo er lidt old-skool - og det er Open Source jo også

Listen indeholder numre som - for ikke-spotify brugere:

Relateret indhold

Kommentarer (6)
Marc Andersen

Jeg har observeret at implementering af små løsninger, som ikke var kritiske for organisationen, virkede fint. Når de så havde bevist deres værdi, så er det som du siger, udvidelse efter behov, ikke budget.

De løsninger, som fik lov til at køre med den originale open source stack, levede i stabilt og performede som de skulle. Hvis funktionen disse løsninger varetog derimod blev lagt over til standardsystemerne (behovet var der jo), så faldt ydelsen typisk betragteligt, men blev til gengæld dyrere: samme antal mandetimer, men med licens for ekstra software, og ekstra licens til den software der styrede software, og så lige licenser for ekstra brugere.

Den generelle modgang bliver ofte ytret i vendinger som "no vendor support" eller "umodenhed". Graver man lidt i det, så finder man ud af, at modgangen rent faktisk mere i "det er kompliceret", "man skal kunne kode", "der er ikke nogen GUI" og lignende. Til dels korrekte, til dels ukorrekte opfattelser.

Der er nok mere tale om berøringsangst tæt fulgt af forkert opfattelse af ansvarsfraskrivelse (man vil gerne pege på en leverandør når noget går galt med software).

Det sjove er, at de fleste bruger open source uden at vide det, men er stadig imod:
https://opensource.microsoft.com/
https://opensource.apple.com/

Jesper Ravn

Jeg tror mange virksomheder fravælger open source, fordi det som udgangspunkt kan være tidskrævende, at servicere, opdatere og overvåge. Især hvis man som virksomhed, primært benytter Microsoft services.

De open source projekter jeg tidligere har set, blev typisk planlagt og etableret af en enkel ildsjæl fra IT. Men når han så forlod virksomheden, stod IT afdelingen tilbage med en hairball arkitektur af system XYZ, som man ikke kunne gennemskue. Et par få eksempler kunne være som følger:

Ekstra servere/services/plug-ins til Kerberos Authentication/SSO, Certifikater/Kryptering, Web Proxy, Backup, Overvågning osv.

Til gengæld tror jeg, at open source vinder frem, hvis de kan anvendes som rene cloud services og således ikke belaster IT afdelingen med speciel viden omkring back-end driften.

Angående sikkerhedsprodukter og features/services, mener jeg i dag, at f.eks. Microsoft, er kommet rigtig langt med deres on-premises og cloud overvågning services. Det betyder, at man som virksomhed, kan udlicitere den komplekse del af IT sikkerheden til rene Microsoft services.

Her ser jeg ikke open source med de samme muligheder.

Ole Kaas

Jeg får heller ikke penge af O'Reilly... men de udmærker sig ved at levere deres elektroniske bøger i et ulåst format (pdf og flere populære e-reader formater). Jeg kan åbne dem i min favorit læser på alle de enheder jeg bruger. Tillige til en pris hvor jeg må sige til andre: Køb den selv.

Jeg har et par gange købt hos andre udbydere, hvor materialet var DRM beskyttet. Der skulle bruges en særlig læser (noget adobe hejs), hvor man maksimalt kunne kopiere materialet til 3 enheder. Desuden kunne der ikke copy-pastes - pænt træls når man lige skal prøve en sides kodeeksempel eller config indstilligner. I den lette ende kunne det "blot" være en låst pdf - hvor copy-paste var no-go. Jeg køber aldrig noget igen der er crippled på den måde.

Ole Kaas

Jeg har to - sådan ca - aversioner mod closed source:

  • Det er ofte beskyttet af en license kode/fil. Hvis det fejler er der ikke andet at gøre end at vente på at leverandøren løser dette/levere en ny. Licenser er noget de fleste leverandører vogter nidkært - er man heldig, har leverandøren en 24/7 support, der kan udlevere en midlertidig licens (f.eks 24 timer). Er man mindre heldig, kan man stille sig op i køen i kontortiden.

  • Hvis man får en "underlig" fejl, er det ikke sikkert den er dækket i leverandørens knowledge base og det er lidet sandsynligt at Google nogensinde har set den beskrevet noget sted. Man må indrapportere fejlen til 1. line support og så pænt vente på at den bliver eskaleret til både 2. level og 3. level. Afhængig af SLA, kan man ringe 24/7 og få fast track på problemet. Med open source, har jeg kunnet google mig til en (halv) løsning, et hint eller noget om hvad der kunne være galt og løse problemet eller lave et workaround.

Per Møller Olsen

Jeg er ret vild med Open Source-løsninger. Men ofte ender det faktisk med at jeg køber software, som i en eller anden udstrækning er baseret på Open Source, fordi det så leveres med en pæn og logisk GUI.

Et godt eksempel er f.eks. Apples serversoftware, som koster den nette sum af 20 $. Det er bare en frontend, men I mine øjne er det godt givet ud for at få lidt point and click.

Et andet eksempel er diverse backupværktøjer, som er baseret på rsync. Hell yes ... jeg betaler gerne 30 $ for at slippe for at skrive stier selv. :-)

Og jeg binder mig ikke mere, end at jeg til hver tid kan skifte frontend - eller i værste fald være nødt til at skrive selv. :-)

Mine kunder er oftest ligeglade, bare det virker (og jo billigere jo bedre).

Når det så er sagt, så er det endnu ikke lykkedes mig at få en grafiker eller fotograf til at bruge Gimp i stedet for Photoshop. Og folk betaler også gerne (nåja ... lettere modvilligt) for at få MS Office, selvom de kunne få gratis alternativer. Jeg tror det handler om at følge sig tryg.

Så i min verden trives Open Source fint til de kedelige rutineting, som ikke kræver ret meget interaktion med brugerne, mens folk helst vil "røre" ved noget de kender.

Mvh. Per

Log ind eller Opret konto for at kommentere