söndag 20 april 2014

D och E

Mytbildningen om FOSS är stark, så jag tänkte, med anledning av en facebookdiskussion, bemöta lite fler myter här.

Myt: Man kan aldrig få se koden till proprietär mjukvara.

Sanning: Proprietär mjukvara kan ha allt från helt öppen källkod, via källkod som kan visas för kunder under vissa avtal, till superhemlig källkod som aldrig visas för någon utomstående under några som helst omständigheter.

Myt: Med FOSS hittar man buggarna blixtsnabbt och communityn publicerar rättningar direkt!

Sanning del 1: Hittandet och rättandet av en bugg går till ungefär så här (alltid, oavsett om det är FOSS eller proprietärt):

  • Någon observerar ett oönskat beteende
  • Någon analyserar kod
  • Någon rättar kod
  • Någon kvalitetskontrollerar (granskar och/eller testar) den rättade koden
  • Någon tillhandahåller en rättad version av mjukvaran för användaren
Det enda led i den här kedjan som möjligen kan hoppas över är kvalitetskontrollen, men annars måste alla steg löpas igenom. Och det tar ungefär samma tid att göra det oavsett om den som gör det gör det för ett FOSS-projekt eller ett företag. Eller, ja, den som jobbar för ett företag har ofta tillgång till bättre verktyg.

Men poängen är att tiden från den första punkten till den sista är stort sett konstant oavsett licensieringsform. Det kan förefalla gå fort med FOSS om communityt får en patch av någon som redan har löpt igenom i princip hela kedjan åt dem. Med en superhemlig leverantör tvingas man lämna över stafettpinnen redan vid den andra punkten ovan, och då kan det verka ta längre tid, helt enkelt för att det blir mer arbete som måste utföras innan det är klart.

Sanning del 2: Det är inte alls säkert att communityt betraktar beteendet som en bugg, eller tycker att den rättning man presenterar är bra, eller förstår/bryr sig i ens problem. Det som händer då är att du får antingen leva utan rättningen eller starta en egen gren av projektet, och i det senare fallet har vi gått från en snabb och enkel rättning till att ha eget underhållsansvar för ett mjukvaruprojekt. Hoppsan.

Utläggning:

De framgångsrika open source-projekten vi hör om är saker som Apache, Postfix, Bind, Python etc. Det är de projekt som uppnått "kritisk massa" så pass att de är självgående och inte har något problem att rekrytera folk, och har så många användare som är beroende av dem att belastningen per organisation är rätt låg att hysta in lite mantimmar på att jaga buggar etc.

Alla open source-projekt är inte lika framgångsrika och mer esoteriska projekt saknar den typen av egen motor vilket leder till att de bara utvecklas så länge som ursprungspersonerna har nytta av det och bara tills de features de behöver är klara. Efter det tenderar de projekten att ruttna.

Inom Piratpartiets IT-grupp känner många säkert till Kannel, den SMS-lösning partiet använde under lång tid men som hade många tillkortakommande vad gällde stabilitet och funktioner. Då koden också var extremt dåligt skrivet var det praktiskt sett så gott som omöjligt att hitta och fixa buggarna.

Det slutade med att Jörgen till slut kastade ut Kannel och skrev en helt egen SMS-gateway  i stället, en lösning som väldigt ofta är en realitet inom den fria mjukvaruvärlden. Det leder till en svårnavigerad djungel av halvfärdiga projekt som alla löser delar av en viss problematik men sällan erbjuder en komplett lösning som enkelt går att anpassa eller utöka utifrån nya behov.

Att plocka russinen ur kakan och tex köra CentOS på en server är bekvämt och enkelt. Någon annan fixar problemen och du slipper betala. Om man däremot är beroende av mjukvara som är väldigt nischad är risken stor att du blir sittande med svartepetter själv, och dessutom kommer andra att börja förvänta sig att du ska fixa skiten.

Myt: FOSS är billigare.

Sanning: Det är inte i första hand licenser som kostar pengar. Det är bara de som syns i boksluten, ja, men det kostar att underhålla sin egen mjukvara också. TCO (Total Cost of Ownership) är inte noll bara för att licenskostnaden är noll.

Myt: FOSS är säkert.

Sanning: FOSS-förespråkarnas argument har ofta ett korn av sanning, men de berättar inte allt. Till exempel berättar de oftast inte att i och med att källkoden är öppen, så kan inte bara snela hestar hitta fel i den; det kan andra också.

Myt: Eftersom man kan kodgranska FOSS går det inte att lägga in bakdörrar i FOSS.

Sanning: Kodgranskning är bra för att hitta designmissar och större klantigheter. Man kan hitta buggar också, men det är mer tur än skicklighet när så sker. Det är knappast svårt för exempelvis NSA att låta en agent infiltrera ett FOSS-projekt och "av misstag" implementera en bugg som ingen hittar men som ger NSA massor av godis.

Så, nu har du fått lite mer insikt i hur verkligheten ser ut i mjukvarans värld. Nästan alla problem med FOSS som jag har beskrivit ovan har sina motsvarigheter hos proprietär programvara; varken FOSS eller proprietärt är någon genväg till paradiset. Man får väga för och emot i varje enskilt fall; när man ska nyutveckla för statens pengar är FOSS att föredra, men annars bör valet av mjukvara inte avgöras av hur den licensieras. Detaljer som är relaterade till licensen kan vara en del av kravbilden, men huruvida det är FOSS eller ej är irrelevant.

Jag får sannolikt anledning att återkomma i ämnet.