Om kodkvalitet och annat

Denna vecka har dominerats av diskussion om kodkvalitet. För mig började det på tisdag morgon med att Henrik Sandklef ringde för att förvarna mig om ett utspel i Computer Sweden där Malin Forsman, i en artikel av Lars Danielsson, går ut och påstår att sluten programvara skulle vara av högre kvalitet en programvara med öppen källkod. Hela artikeln är konstig. Vad gäller kodkvalitet så finns det naturligtvis massor av exempel på kod men både hög och låg kvalitet både bland fri programvara och sluten dito. Så egentligen är hela påståendet lite konstigt.

Jag läste artikeln och konstaterar att den är full av känd FUD och direkta felaktigheter. Jag bestämde mig snabbt för att inte bemöta artikeln. Jag sökte lite på juristens namn och kunde snabbt konstatera att hon jobbat på Microsoft under några år. Jag ringde tillbaka till Henrik och berättade det. Ingen av oss var väl direkt förvånade, men jag återkommer till det senare.

På de e-postlistor där jag är med diskuterades hur och om artikeln skulle bemötas. En sak som man hänger upp sig på är att det inte i artikeln står att Forsman jobbat på Microsoft utan att hon i artikeln framställs som neutral medan Anders Liling, som också uttalar sig i artikeln, presenteras som ”vd på Stockholmsföretaget Redpill som erbjuder konsult- och supporttjänster för öppna program”. Klart att det är fel att det framställs på det sättet. Men skall jag vara ärlig så tycker jag inte att var man tidigare jobbat skall förhindra att man får gå ut och tycka och tro saker. Skall man spekulera i varför Forsman gör detta utspel så tycker jag det är mer relevant var Forsman gör idag. Det tycker jag inte har framkommit så mycket. Enligt sin presentation på Advokatfirman Westermark Anjou jobbar Forsman som jurist inom områden som till exempel Immaterialrätt, Programvarufrågor och Informationsteknik. Hon har alltså allt att vinna på konstiga proprietära lisencer och villkor. Hon är också medlem i Medlem i Svenska föreningen för upphovsrätt (SFU), där till exempel Microsoft är medlem. Jag misstänker att denna förening inte riktigt har sett fördelarna med fri progamvara för sina medlemmar ännu.

Flera valde att kommentera artikeln till tidning. Det ledde till ytterligare en artikel där några av kommentarerna från läsarna redovisades.

Tillbaka till artikeln. Jag kommer som sagt inte att kommentera artikeln – det har redan Anders Lindbäck och Svenska Linuxföreningen gjort på ett bra sätt i en debattartikel i samma tidning som Forsmans utspel. Märk att Anders debattinlägg i princip står okommenterat medan Formans utspel har över 270 kommentarer och ytterst få håller med henne.

Jag kommenterar inte på IDG, det tar för lång tid att hänga med i kommentarerna och det är lätt att skriva en kommentar men det tar lång tid att sedan följa kommentarerna för att se om min kommentar bemöts någonstans. Men några av kommentarerna (jag har skummat dem bara, det är för många för att läsa alla) tycker jag borde besvaras så jag tar dem här.

”timb45” (tyvärr är de flesta som debatterar anonyma) skriver:

Att tjäna pengar på att sälja en produkt istället för att supporta skapar ju per definition bättre förutsättningar för att optimera kvalitén. Tvärtom är det väl så att öppen källkodsleverantörer som har en armada av konsulter och supportpersonal snarare ser varje bug som en garanti för fortsatta intäkter.

Att ”ge bort” en produkt för att skapa ett beroende som sedan leder till påtvingad support är verkligen inlåsning. För även om koden är fri och öppen är kompetensen inte det.

Detta är naturligtvis inte riktigt och visar på att man inte förstått vad det handlar om. En styrka med fri programvara är att den främjar konkurrens. En bugg är knappast en garanti för fortsätta intäkter utan snarare en uppenbar risk att någon annan erbjuder en bättre tjänst eller produkt. Kanske från samma kod. Även leverantörer av sluten programvara tjänar pengar på support men gör det i skydd av den hemliga källkoden. Här kan man möjligen se ett incitament till att skriva dålig kod.

Sedan talar ”timb45” om inlåsning. Har man stängd kod enligt ovan och dessutom kan låsa in kunderna genom att inte följa standarder så blir det ännu svårare för kunden.

I en kommentar till den uppföljande artikeln skriver Patrik Löwendahl (tack för att du inte är anonym) angående fördelen med att kunna modifiera fri programvara inhouse om man vill och har personal som kan det:

Det här är ett av de sämsta argumenten med OSS. Jag /vill/ inte bygga operativsystem. Jag köper OS och färdiga program för att slippa, istället kan jag anställa kompetens som fokuserar på /min/ kärnverksamhet. Det är att vara affärsmässig, satsa på det som som får det att skilja sig från dina konkurrenter. Att ta över OSS källkod kanske gäller för IT företag, men knappast för en kommun.

Jag håller med om att ingen vill bygga operativsystem, men detta gäller så mycket mer än operativsystem. Operativsystem är hyllprodukter som skall göra det de skall. Men Löwendahl skriver om att han vill anställa personal som fokuserar på sin kärnverksamhet. Borde det inte vara bra om han även kunde anpassa systemen så de också fokuserar på hans kärnverksamhet? Att man har möjligheten att anpassa betyder inte att man måste. Om en programvara inte riktigt passar perfekt för det syfte jag vill så kan jag om programmet inte är fritt bara be om en offert från ett enda företag på att få det förändrat. Är programmet däremot fritt kan jag ta in offerter från flera oberoende företag för att få det anpassat. Känns inte det mer affärsmässigt? Att ställa sig i en beroendeställning till en leverantör är varken bra eller affärsmässigt anser jag.

Hur jag än vrider på Löwendahls inlägg kan jag inte få det till ett argument mot fri programvara.

Nu är det söndag. Jag sitter hemma med en bunt med verifikationer som skall gås igenom. Jenny håller på att slipa i vårt nya arbetsrum på nedervåningen och Albin leker med sin kusin Simon och Vilma sover på gården. I morgon börjar en ny spännande vecka.

6 reaktioner på ”Om kodkvalitet och annat”

  1. >> (tack för att du inte är anonym)
    Har man en åsikt så måste man våga stå för den, annars är man sådär lagom trovärdig anser jag 🙂

    Jag påstår inte att argumentet är mot fri programvara, jag säger att det är ett av de sämsta argument man kan försöka använda /för/ OSS.

    De flesta större och seriösa programvaruföretagen låter dig anpassa deras programvaror med hjälp av någon form av programmeringsmodell eller integrationspunkter. Med dem kan jag oftast fokusera på min affärsverksamhet och lägga till det som är specifikt för mig till den generella produkten.

    I den typ av verksamhet jag rör mig så är det sällan OS du är intresserad av att anpassa utan snarare affärssystem, crm, portaler, ordbehandlare och dylikt. Att bygga utökningar till dem och integrera dem med varandra kräver oftast inte öppen källkod så i de fallen tillför OSS inte så mycket för att jag skall kunna vara ”affärsmässig”.

    Jag kan tex bygga programvaror med .NET Framework och Java (även innan Java blev någon form av kvasi-OSS). Att ha tillgång till källkoden i de båda fallen tillför inget ur ett ”affärsperspektiv”. Samma gäller tex Sharepoint, jag har en enorm mängd möjligheter att anpassa sharepoint till min verksamhet utan att ha tillgång till sharepoint-källkoden eftersom det är byggt med massvis av utökningsmöjligheter. Det innebär bla att jag kan fokusera på att hantera endast min källkod och inte för hela produkten, med alfresco blir det lite annorlunda, där har jag en stor kodbas som jag inte ens förstår som jag också får underhålla om jag vill använda deras kod.

    Så även om fri källkod ger mig ”fördelar” vad gäller produktens fortlevnad så är jag sällan intresserad av att hantera det ansvar, kravet på kompetens och kunskap som tillgång till källkoden för tex Open Office skulle ge mig när det räcker med kompetens för tex Visual Studio Tools for Office och integrationsmöjgliheterna där för att faktiskt anpassa ordbehandlaren till min verksamhet.

    Så igen, jag säger inte att det är ett argument /mot/ OSS utan jag vill mena att det är ett ganska haltande argument /för/.

  2. Patrik Löwendahl:

    Tack för ditt välskrivna inlägg. Kul att kunna föra en saklig debatt.
    Jag ser också att jag missuppfattat eller dragit för stora växlar av
    ditt inlägg på IDG där du skriver att det inte är ett argument mot utan
    ett klent argument för fri programvara.

    Men jag hävdar fortfarande att det är ett starkt argument för. Som jag
    skriver tidigare innebär inte möjligheten att anpassa en produkt att man
    måste göra det. Det är inte ens önskvärt att man gör det. Precis som du
    skriver innebär det då också att man måste hantera framtida patchningar
    av produkten manuellt, eller köpa in förändringen och underhållet från
    någon annan.

    Om man förändrar koden är det bästa att skicka förändringen till
    upphovsmannen av programmet och hoppas att de lägger in den i den
    officiella versionen så slipper man problemet.

    Men till ditt argument. Du nämner några programvaror och att
    programvaror ofta låter sig anpassas via någon programmeringsmodell
    eller integrationspunkter. Det är ju kalas! Har man en programvara som
    är perfekt och låter mig modifiera den och samtidigt på ett naturligt
    sätt isolera min egen kod så finns det ju ingen anledning att ändra
    eller läsa koden.

    Men vad händer om jag skulle sakna ett visst anrop eller parameter? Jag
    inser att den måste finnas i programmet men jag kan inte nå den via något
    api, i alla fall inte enligt den dokumentation jag fått. Jag kontaktar
    leverantören och av någon konstig anledning vill de inte ge tillgång
    till den parametern. Alternativt säger de att det eventuellt kommer att
    vara med i nästa version.

    Nu är jag i ett låst läge och källkoden hade varit bra. Så jag hävdar
    fortfarande att det är ett mycket starkt alternativ för, men jag är
    lycklig så länge jag slipper nyttja det.

    /Marcus

  3. >> Kul att kunna föra en saklig debatt.
    Det är lätt när man diskuterar med vuxna människor som har annat än akademisk erfarenhet 😉

    Jag tror att vår meningsskiljaktighet beror på att vi jobbar med olika typer av projekt och har olika typer av krav.

    Vad gäller anrop och parametrar så brukar det vara ett väldigt komplext arbete att ”lägga” till i stora och komplexa produkter. Oftast finns inte parametern där av en anledning och om ett API är privat så betyder det att de som byggt produkten inte förväntar sig att det används på några andra sätt än de som produkten gör.

    Min erfarenhet är att en sådan ändring kanske verkar enkel vid ett första ögonkast men är oftast extremt komplex i praktiken, för att inte tala om det som du själv tagit upp: versionshantering i framtiden med nya patchar och versioner från upphovsmakaren.

    Vill man ta det ansvaret själv och bygga kompetens runt kärnan i produkten och anser att det hjälper min affär (min verksamhet brukar sällan stå och väga pga avsaknaden av ett API eller ett par saknade parametrar) då skall jag ta över ägandet av koden och investera i den kompetens som behövs. Men i de allra flesta fall mår min verksamhet bättre av att låta bli och jag skulle vilja påstå att de som argumenterar för att ändra APIer snarare har ett kod-centriskt tänkande än ett med affärsfokus.

    Jag skulle också vilja hävda att i slutändan handlar det om att den enda kod jag vill äga och ha ansvar över är den kod som ingår i mitt strukturkapital och gör min affär unik jämfört med mina konkurrenters.

    Ramverskoden för Java eller Office bidrar sällan till mitt strukturkapital utan är mer ofta en kostnad och jag vill inte ha kostnader, jag vill ha strategiska investeringar.

  4. Patrik Löwendahl:

    Jag tror att inte att våra system och projekt skiljer så mycket faktiskt. Jag tror att vi i grund och botten är överens om att det inte alltid (eller mycket sällan) är önskvärt att använda möjligheten att anpassa koden genom att modifiera en stor kodmassa man annars inte behöver förvalta.

    Men sedan skiljer det lite. Jag tror att du tittar i din värld med de projekt du jobbar medan jag försöker se till alla aspekter. Jag hävdar att det trots allt finns ett stort värde i att möjligheten finns. Du skriver själv:

    ”Vill man ta det ansvaret själv och bygga kompetens runt kärnan i produkten och anser att det hjälper min affär (min verksamhet brukar sällan stå och väga pga avsaknaden av ett API eller ett par saknade parametrar) då skall jag ta över ägandet av koden och investera i den kompetens som behövs”

    Detta kräver ju att det finns en möjlighet att göra det vilket jag förespråkar. Sedan är det ju som du skriver i de flesta fall inte ekonomiskt försvarbart att göra det, men man behöver inte göra det ensam. Om du vill ha en funktion som inte leverantören vill implementera kanske det finns ett incitament för en extern aktör att implementera den och erbjuda den till dig och de andra som vill ha den.

    Ett annat scenario kan vara till exempel en Kommun som behöver en viss anpassning av ett system och kan välja att göra den anpassningen tillsammans med några andra kommuner och i samma veva lägga förvaltningen på en extern, förhoppningsvis lokal, partner.

    Nyckeln är möjligheten och valfriheten och att denna även gäller andra, inte bara mig. Slipper man så är det så klart bra.

    I övrigt håller jag med dig i alla dina argument. Jag vill inte heller förvalta kod som inte ger mig ett försprång gentemot mina konkurrenter. Men samtidigt jobbar jag med än gärna tillsammans (finns flera former för det) med mina konkurrenter på sådan kodmassa som vi ändå har gemensamt eftersom det för den totala utvecklingen framåt. Ett bra exempel på detta tycker jag är Linux-kärnan som idag utvecklas till stor del av olika företag som är konkurrenter i mycket annat.

    Som sagt, vi är överens om det mesta men jag hävdar fortfarande, envist, att det är en stor fördel att kunna anpassa programvaran. Jag tror också att vi är överens om att det är mycket positivt för framtidssäkerheten.

  5. Man får vara envis, men det betyder inte att man har rätt 😉

    Skämt å sido, jag förstår din ståndpunkt men jag står också fast vid att argumentet, även om det är för OSS, är i klenaste laget och knappast ett som får vågen att tippa över till OSS fördel.

    Att själv, eller med andra, ta ägandeskap över en kodbas är ett sätt att få som man vill i produkten men det finns andra som funkar bra men annorlunda där jag inte behöver äga någon kod. Tex, och det här gäller ju för både OSS och stängd programvara, feature requests via user groups eller dylikt (MS har ju tex Connect där man kan rösta på features, med tillräckligt många röster så lyfts featuren in i planeringen). Det är de här möjligheterna som gör att jag inte tycker att ”ägandet” av koden tillför så mycket till OSS fördel.

    Men det är ganska tydligt att den här frågan är väldigt tydligt baserad på omständigheter, erfarenheter och frågan om vad man tycker är viktigt. Vilket är det som gör att jag inte tror att OSS kommer att bli den all rådande ordningen pga av tillgång till källkoden utan det är andra faktorer som måste spela in som är mer affärsdrivna än så.

    Men i stort överrens, otroligt 😉

  6. Patrik Löwendahl:

    Japp, i stort sett överens. Jag tror inte vi kommer längre utan jag tackar för debatten. Ha det bra. Hoppas vi får möjlighet att diskutera fler gånger … 🙂

    /Marcus

Kommentarer är stängda.